Implement Fusion context_names injection

[dmann000]

Umbrella issue for Fusion context_names support. Phases 0 and 1 have shipped; this body is the current state.

Design documents: docs/design/fusion-context-phase-0-spec.md and docs/design/fusion-context-phase-1-spec.md, both on main. The originally cited docs/design/fusion-context-injection.md was never merged — PRs #22 and #72 carried it and are now closed as superseded, so references to that path are dangling and should point at the phase specs.

Shipped

• Phase 0 — capability-map contextScope (Integration: Fusion Phase 0 prerequisites + capability-map schema-walk fixes (#96, #97) #98). Records per endpoint whether a context is fleet-scoped, array-scoped or unknown, with provenance, so injection can be gated on data rather than inference.
• Phase 1 — session-scoped context and client-side validation (Fusion context_names Phase 1: session-scoped context and client-side validation (#25) #109). Delivered together, which does not match this issue's original phase split:
  • Connect-PfbArray -Context, -Kind, -AllArrays
  • Set-PfbContext, Clear-PfbContext, Invoke-PfbInContext (originally listed as Phases 2 and 3)
  • Central injection at the single Invoke-PfbApiRequest choke point — no existing cmdlet gains a -ContextNames parameter
  • Four client-side gates (capability, cardinality, kind-vs-scope, admin locality) that fail fast instead of relaying the server's assorted rejection codes
  • Cardinality is data-driven from the capability map (tools: check the Fusion context_names cardinality assumption against the spec #73), replacing the falsified "every GET is multi-context, mutations are size-1" rule

Phase 2 — remaining scope

• Fusion Phase 2: allow_errors and the partial-failure errors envelope #159 -- allow_errors. Not implemented; the drift report carries an annotation saying so. The rule established by live testing is that tolerance keys off the value count, not the parameter's form: allow_errors is honoured only when context_names carries 2 or more values. A consequence worth designing against — -AllArrays -AllowErrors can never yield a partial result, because a single resolved array is still a size-1 context.
• Fusion Phase 2: 403 reconnect amplification on the Set-PfbContext path #160 -- 403 reconnect amplification. The connect-time GET /admins probe meets the reconnect gate, which fires on 403 as well as 401 by design. Under a restricted management-access policy that costs roughly three round trips and a spurious re-login, now paid on the common Set-PfbContext path. Non-fatal — the catch contains it. This is derived from the code path and deliberately was not live-measured: the measurement needs an out-of-band management-access-policy change on the lab array, and the last such change destroyed the test account's API token. Any fix changes reconnect logic shared by every cmdlet, so it wants its own design pass rather than a patch.
• Fusion Phase 2: context_ids and context display surfacing #161 -- context_ids and display surfacing.

Related, tracked separately

• Drift report AST scanners miscount coverage two ways (private helpers credited; variable-keyed injection not) #113 — the drift report still lists context_names as a 269-endpoint systemic gap even though Phase 1 injects it, because the AST scanner only recognises literal-key assignments and the injection site is variable-keyed. The gap annotation should be deleted when that lands.
• contextScope: topology-group write verbs rest on provenance: default while the family's reads are live-tested fleet #110, x-pure-block-remote-execution is unusable as a runtime signal until the x-pure-incomplete-gre set is excluded #111, contextScope has no version dimension #112 — contextScope follow-ups surfaced by Phase 1: topology-group write provenance, x-pure-block-remote-execution usability, and the absent version dimension.
• Fusion Fleet/Realm management cmdlets (realm-connections, topology-groups, remote-realms) #38 — eight topology-group endpoints have no cmdlet; Fusion-specific endpoints not covered by this work.
• Workload preset cmdlets are non-functional: every write and every name-scoped read needs context_names=<fleet> #79 — workload preset cmdlets need context_names=<fleet> on every write and every name-scoped read.

[juemerson-at-purestorage]

Scope refresh — the design has moved substantially since this was filed, and both stated blockers are resolved.

Both original blockers are cleared

• Design sign-off: PR Design spec: Fusion context_names injection #22 (rev 2) and PR Design spec rev 3: cardinality is not the HTTP verb (stacked on #22) #72 (rev 3, stacked on it) now exist.
• "Confirm the capability map records context_names per endpoint": done. The map records it
  on 270 endpoints in systemicGaps (311 across all confidence levels), and 376 operations
  declare it in fb2.28. This item can be struck.

The three-phase breakdown in the body is now wrong

Rev 3 redistributes it. Replacement, per the "Phasing" section of the design:

Phase 1 — Connect-PfbArray -Context; the PfbContext object (Kind/Form, reserved
AllowErrors); central capability-gated injection with the §5 ordering fixes;
Set-PfbContext/Clear-PfbContext; Invoke-PfbInContext; kind-vs-scope validation; the
data-driven cardinality rule; the contextScope map field (§12); the authorization_model
precondition; connect-time staleness warning; -AllArrays and its membership-resolution path.

Phase 2 — allow_errors end-to-end: surfacing, default rules, HTTP 207 + errors branch.

Phase 3 — context_ids; an explicit multi-value mutating fan-out helper; context display in
Get-PfbArrayConnection; Realm as a context kind.

Note what moved: Set-/Clear-PfbContext, Invoke-PfbInContext, contextScope and -AllArrays
are all Phase 1 now, and Phase 2 is redefined around allow_errors rather than being the
ergonomics layer.

Dependency links missing from the body

• Blocked on Move context_names component resolution from tools/lib into Private/ before the Fusion injection path is built #74. Component resolution must move from tools/lib/ into Private/ as the
  implementation PR'"'"'s first commit (rev 3 §5 item 3) — not as standalone work. Without it the
  cardinality rule gets silently duplicated between the generator and the runtime.
• Blocked on Tracking: coordinated changes to the capability-map generator and schema (#71, #82, #83, contextScope) #84 PR 2 for the contextScope half specifically, which needs the
  schemaVersion 2 bump.
• Unblocks Workload preset cmdlets are non-functional: every write and every name-scoped read needs context_names=<fleet> #79. All six workload-preset cmdlets are non-functional today and start working
  once this lands — that is the concrete user-visible payoff.
• Contract with Fusion Fleet/Realm management cmdlets (realm-connections, topology-groups, remote-realms) #38. Get-PfbTopologyGroup must emit a top-level Name, or -AllArrays
  membership resolution silently no-ops. Recorded on Fusion Fleet/Realm management cmdlets (realm-connections, topology-groups, remote-realms) #38.

Open question that gates #79 closing

Rev 3 Open Question 7 — what happens when a fleet-scoped endpoint is called with no context set.
The design'"'"'s own recommendation is to throw client-side. This needs answering before #79 can be
closed, since it determines whether the preset cmdlets fail fast or emit a confusing wire error.