MEMBERS-DIRECTORY-001H — Preserve a reviewed replacement across saved-photo removal #633

Parent: #504. Connected release remains owned by #507.

Officer impact: In the preserved future My Account interface, removing the current saved photo will no longer silently discard a replacement photo the person is still reviewing, and keyboard focus will move to the next relevant photo action. This connected interface source remains unavailable on production.

Officer documentation: Update SYSTEM_DESIGN.md, IMPLEMENTATION_PLAN.md, SECURITY.md, and the existing optional-directory diagram, one-sentence text alternative, and source-review procedure in docs/officers/EVENTS_SHOP_MEMBERS.md.

Deployment evidence: None at issue creation. This is source-only interface hardening. memberDirectoryAvailability.ts must remain byte-for-byte false; no Firebase, provider, account, production-data, sign-in, or live website action is authorized. Closure must distinguish source/test/merge evidence from the unchanged inert #623 production preview.

Atomic outcome

Preserve a local selected-photo review across a confirmed removal of the current saved photo, and restore keyboard focus to a useful persistent or next-step control.

Invariants and transitions

• Rename the destructive action to Remove current saved photo so it cannot be confused with the selected local replacement.
• Selecting/reading/reviewing a replacement remains local and creates no request ID or service call until explicit Save profile photo.
• A confirmed remove with authoritative readback preserves the current local reading or ready draft and its identity. It updates only the current saved-photo state and revision.
• A later explicit Save of the preserved ready draft creates one new request ID, sends the preserved bytes once, and uses the authoritative revision returned after removal.
• A confirmed remove does not change the officer-finder visibility setting.
• A definitive rejected remove with successful authoritative readback keeps the local draft available for review/retry and associates the fixed error with the remove control.
• An unknown remove outcome or any post-mutation authoritative readback failure clears the local draft/data URL, hides connected controls, and exposes the existing unknown/unavailable recovery state. It must not invite a duplicate mutation.
• After confirmed removal, focus moves to Save profile photo when the preserved draft is ready; otherwise it moves to the persistent Add/Replace file input. If authoritative readback says a current saved photo still exists, the visible remove action remains a valid focus target.
• App, UID, unmount, reselection, Cancel, FileReader, image-render, mutation, and readback generations remain fenced. A stale completion cannot restore bytes, focus, state, or a service call into another context.
• The source-controlled availability boundary stays false. The default My Account branch remains an inert zero-context, zero-request-ID, zero-call preview.
• Photo upload remains independent of visibility. Do not add photo-as-query, recognition, matching, embeddings, similarity, biometrics, roster authority, or membership proof.

Exact ownership

• src/pages/account/MemberDirectoryProfile.tsx
  • preserve only the current local draft/read identity across a confirmed remove;
  • rename the remove action and add bounded post-remove focus intent.
• src/pages/account/MemberDirectoryProfile.test.tsx
  • one separately named MEMBERS-DIRECTORY-001H block and the minimum expectation updates for the renamed action.
• SYSTEM_DESIGN.md
  • one separately named MEMBERS-DIRECTORY-001H source-only paragraph.
• IMPLEMENTATION_PLAN.md
  • one separately named MEMBERS-DIRECTORY-001H current-source paragraph.
• SECURITY.md
  • one separately named MEMBERS-DIRECTORY-001H/RISK-042 source-ledger row immediately after released 001G; preserve active OAUTH-001A2L — Bound Strava activity/statistics JSON and cancel the unread statistics body #616's OAUTH-001A2L/RISK-024 hunk byte-for-byte.
• docs/officers/EVENTS_SHOP_MEMBERS.md
  • only the existing optional-directory Mermaid/one-sentence text alternative and one separately named source-review procedure for this change.

Required tests

• Capture trustworthy RED on the old runtime for draft loss and/or focus loss.
• A ready reviewed draft survives one successful remove; no upload happens before Save.
• The subsequent Save sends the exact preserved content once with the refetched revision.
• A FileReader completion that remains current across a confirmed remove can finish locally; stale/reselected/context completions remain inert.
• A definitive rejected remove with successful readback preserves the draft and fixed remove error.
• Unknown remove outcome and post-success readback failure discard the draft/data URL and expose no Save retry.
• Confirmed remove restores focus correctly with a ready draft, a reading/no-ready draft, no draft, and authoritative readback that still has a saved photo.
• Visibility and saved-thumbnail fallback behavior remain unchanged.
• The default unavailable branch still obtains no directory context and creates no request ID or service call.
• Existing profile races, upload review, accessibility, mobile, privacy, and error tests remain green.

Explicit exclusions

• Account.tsx, Account.test.tsx, admin People finder, Account CSS, and all client service adapters.
• The separate inbound WebP-magic contract hardening identified after MEMBERS-DIRECTORY-001G — Clear People-finder results and distinguish unavailable photos #631.
• Functions, Rules, indexes, schemas, repair/backfill, packages, workflows, or release controls.
• Privacy-notice approval, AUTH-003 capability design, role/MFA changes, or MEMBERS-DIRECTORY-001C — Release and verify the opt-in officer photo directory #507 activation work.
• Firebase/provider configuration, deployment, sign-in, accounts, production data, real names/photos, or live connected behavior.
• Both active OAUTH-001A2L — Bound Strava activity/statistics JSON and cancel the unread statistics body #616 Strava files and its separately named SECURITY OAUTH-001A2L/RISK-024 hunk.

Claim protocol

Assign the issue and post a timestamped CLAIMED marker naming the exact branch and released base before any edit. The claim remains active through reviewed merge, exact-main audit, closure, and explicit release.