Keep type-permission retry focus inside the card editor

[Chris0Jeky]

Purpose

A keyboard user can activate Refresh permission in the card editor, receive a successful permission read, and then lose focus when the retry controls unmount. The next Tab can escape the modal's focus trap into the page behind it.

This PR takes the focused accessibility slice from #3030 without entering the parked permission-ordering work in #3072. The contract is:

• the permission live region remains mounted and empty while idle, so later transitions are announced;
• while the retry read is pending, the recovery control remains mounted;
• when that control owned focus and the read succeeds, focus moves to the newly enabled work-item type selector before the recovery controls leave;
• a background refresh never steals focus from another control;
• permission classification, retry ordering, write authorization, drafts, archive ownership, and server behavior do not change.

Red → green evidence

RED — proven before production changed. Commit 075033a12245f2ac86b4c691a109566c2ead505d added only CardModalFormPermissionFocus.spec.ts. CI run 34911759194, Ubuntu frontend job 104200696307, passed lint, typecheck, build, and PWA validation, then failed in Run frontend tests with coverage thresholds because successful recovery neither retained the live region nor placed focus on the enabled selector.

GREEN — exact hosted head. Commit a220887411965dd12159511d05e8ee011467260b adds the focused ownership-aware transfer and persistent live region.

• Smart CI Self-Test run 34912236004: success.
• CI Extended run 34912236144: success.
• Main CI run 34912236190: all 17/17 jobs are terminal with no failure, queued, in-progress, or null-conclusion job. The GitHub Actions parent run still reports in_progress, which is workflow-finalization/API lag rather than an executing or failed job.
• Exact-head coverage includes both frontend operating-system lanes plus lint, typecheck, production/PWA build, security, architecture, backend/API, docs governance, release contract, and Windows helper checks.

Scope

• Exactly two commits and two files ahead of main: one focused component regression and CardModalForm.vue.
• Focus is restored only when the retry control initiated/owned the interaction and focus has not deliberately moved elsewhere.
• Existing CardModal.spec.ts already proves the first board read can fail, the explicit retry can succeed, and the selector then becomes writable; this PR pins the component-level focus/live-region contract at that transition.
• The separate 403/404 classification, permission-ordering, cancellation-comment, product-doc, and older tautological-test residuals remain outside this slice.

Refs #3030

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-15T00:26:46.199398Z	a220887	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a220887411

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve the retry control through the real recovery transition

When the initial permission read fails and a keyboard user activates this button through CardModal, refreshPermission() synchronously sets permissionRecovery to true. Because CardModal.vue passes both permission props with && !permissionRecovery, this condition immediately becomes false and unmounts the focused button before the request settles. The watcher therefore sees neither the checking state nor the later successful transition, so focus still falls to <body> rather than moving to the enabled selector—the production flow the change is intended to fix. The new component test misses this because it drives a checking→success prop sequence that CardModal never supplies.

Useful? React with 👍 / 👎.