[PIR #1463 follow-up] Review/arch: capture the key reuse lesson (avoid live-architect dependency; resolve() = structural safeguard)

[amrmelsayed]

Doc-only follow-up to #1466 (merged). Adds the reuse lesson the architect asked to preserve in the durable artifacts, for the next person adding a Stream Deck key:

• Avoiding the live-architect dependency beat handling it carefully. The deck fires a name and delegates main-else-first to VS Code, so the three registry failure modes (empty list, transiently-missing main, live row behind a dead PTY) are simply not this key's problem rather than mitigated by it — reaching for OverviewData.architects would re-import all three.
• The wrong-architect safeguard is structural, not conventional. resolve() is shared by the press path (onKeyDown) and renderTo, so face and action cannot drift — one resolution, the name you see is the name you open.

Added to codev/reviews/1463-*.md and the arch.md Stream Deck integration bullet. No code change.

Refs #1463.

[amrmelsayed]

Integration review (streamdeck architect) — APPROVE. Docs only: the review artifact, the arch.md Stream Deck bullet, and protocol bookkeeping. No code, no manifest, no assets.

It carries the two decisions this lane produced that a future contributor would otherwise re-derive — avoiding the live-architect dependency beat handling it carefully, and the wrong-architect safeguard is structural rather than conventional because resolve() is shared by the press and render paths. Both are worth the words precisely because the next person adding a key will reach for OverviewData.architects by default, and because a safeguard that holds by construction reads identically in a diff to one that holds by discipline.

On why this is a second PR at all — that is my sequencing, not the builder's. I asked for these additions after #1466 had already merged, so the artifact they belong in had shipped. Asking a phase earlier, before the pr gate, would have carried them in the original PR. This is the same shape as the post-merge porch stamp discussed on #1446: an artifact the protocol produces after its own completion has no authorised way home, and it lands as an unaccompanied follow-up PR with no gate record to corroborate against. Two live instances of it now sit open at once (this and #1464).

Practice change on my side: review-artifact content requests go to the builder before the pr gate, not after the merge.