docs(design): commit the Fusion context injection umbrella design (rev 5)

[juemerson-at-purestorage]

Commits the Fusion context injection umbrella design as rev 5 at docs/design/fusion-context-injection.md.

Why this, now

Revs 2 and 3 of this document only ever existed on unmerged branches — #22 and #72, both now closed as superseded. That left every reference to docs/design/fusion-context-injection.md dangling, including the one in the drift report's own annotation file, which had to be repointed at the phase-1 spec while Phase 1 was being merged.

The two specs already on main (fusion-context-phase-0-spec.md, fusion-context-phase-1-spec.md) are implementation-scoped: they describe what the code does. This document is the umbrella design, and it is deliberately broader. What it carries that nothing on main does:

• the allow_errors design, which Phase 2 still owes — including the rule that tolerance keys off the context's value count rather than the parameter's form, so -AllArrays -AllowErrors can never produce a partial result
• the phasing, and the alternatives considered and rejected
• Appendix A, the empirical basis: every claim about wire behaviour measured against real arrays rather than read from the spec
• Appendix B, the spec defects the design works around, and Appendix C, the figures the counts rest on
• Appendix E, the revision history that keeps the withdrawn "every GET is multi-context" cardinality rule traceable to the live testing that disproved it

What changed from rev 4

No design statement changed. The revision is limited to three things:

1. Status header and implementation-status table naming what shipped (Phase 0 in Integration: Fusion Phase 0 prerequisites + capability-map schema-walk fixes (#96, #97) #98, Phase 1 in Fusion context_names Phase 1: session-scoped context and client-side validation (#25) #109) and what remains (Implement Fusion context_names injection #25). Rev 4 was written pre-implementation, so committing it in future tense would have been misleading.
2. Attribution of the API architecture consult to the FlashBlade product team rather than to a named individual.
3. One vendor documentation sentence paraphrased rather than reproduced verbatim. The claim it supports — that the cross-array gate is about how an admin authenticates, not where its access policies are mapped — is unchanged.

Notes for review

• Docs-only; no cmdlet, test or generated artifact is touched, so the live-testing mandate does not apply here.
• The body reflects the settled answers where the code diverged from the original draft: the permission gate keys on is_local, and Phase 1 shipped Set-PfbContext/Clear-PfbContext/Invoke-PfbInContext together rather than across later phases.
• Every repo path the document references was checked to exist (12 of them).