A hub activated on the wrong NodeType stays wrong — fixing resolution does not un-pin it #1104

Found while fixing #1077. This is the defect that intermittently reds PRs whose diffs cannot reach it, and it currently blocks PR #1103.

What happens

The plugins gate fails on Store/Catalog with compile=Ok render=ok tests=FAILED, "No renderer is registered for area Tests on hub Store".

The decisive evidence is the available-areas list in the failure: it is, item for item, ConfigureDefaultNodeHub's set (AddDefaultLayoutAreas + Education + Domain areas + Invite) — and not one area from Store/Catalog's compiled configuration. Hub Store was serving the mesh default configuration rather than its own.

Two hypotheses are ruled out by the same run, which printed which node hosted each Tests run:

• Not "the probe landed on a type path." Store is the Store package's root, retyped to Store/Catalog by the installer — a correctly-typed instance.
• Not "pre-existing instance vs fresh probe." Store/Plugin used a pre-existing instance and passed.

Why #1055 did not close it

It recurred on a commit that already carried #1055's fix (run 31361446933 at 06:18Z; #1055 merged 04:39Z).

Not cached is not not-pinned. A hub is pinned by address in Mesh.GetHostedHub and never re-reads its node's NodeType. So repairing the resolution path does nothing for a hub that a bad resolution has already activated — the wrong configuration is latched for the hub's lifetime. The only existing thing that un-pins it is PackageInstaller's DisposeRequest, which is fire-and-forget and conditional on the placeholder dance having run.

Why it deserves its own issue

• It is intermittent and cross-cutting: main's gate was green at 10:53Z and the same plugins checkout failed at 11:39Z. It reds PRs by lottery, and the failing PR's diff is irrelevant — one victim's diff was three files (MessageService.cs plus two tests).
• It is a framework defect, not a plugins defect. A hub serving the default configuration for a correctly-typed node is wrong regardless of who installed the node.
• It blocks The plugins gate blamed a compile break for a failure that compiled fine #1103 (the The plugins gate reports 'does not compile — a public API changed' when nothing failed to compile #1077 message fix), which cannot merge while this job is red.

What NOT to do

🚨 No band-aid: do not continue-on-error the gate, allow-list Store/Catalog, add a retry around the probe, or widen a timeout. The gate catches real public-API breakage — plugin source is Roslyn-compiled from mesh content, so a repo-local grep cannot prove a deletion safe (this is how AddSkillSource broke 8 NodeTypes). Weakening it is worse than the bug.

Where to look

• Mesh.GetHostedHub — the address-keyed pin, and whether anything can invalidate it when the node's NodeType changes.
• PathResolutionService.SynthesizePartitionRoot and PackageInstaller — both carry comment blocks with this ledger; they now pose three questions rather than two.
• PackageInstaller's DisposeRequest — fire-and-forget and conditional; a retype that races it leaves the hub pinned.

Un-pinning an already-activated hub needs a repro and a design decision, not a guess — which is why #1103 documented it rather than attempting it.