docs(19.7-09): deferred items for the gap closure

B-IN-05 (deferred, the shared confirm primitive), B-IN-06 (no fix
needed), the admin:token:revoke event, the OIDC decision (resolved), the
local go.work retarget, the demo pins, the release order with
PHASE197_RELEASED, the lenient link code parse and one offline-build
flake; the plan 05 test-commit entry is superseded by the release.

.planning/phases/19.7-generic-mcp-module/deferred-items.md

@@ -146,8 +146,11 @@ was changed by the plan that recorded it.
   pinning summercms v0.4.4 (the demo's release build, oauthserver v0.1.2,
   Journal v0.2.3) lack them until they require the next framework tag
   (v0.5.0 at phase completion, after the user's go-ahead).
+  **Gap closure (19.7-09):** the same holds for every framework fix of plans
+  06 and 07; they ship together in v0.5.0 (see "Release order after the gap
+  closure" below).
 - Plan 05 test commits are local and untagged (found during 19.7-05 Task 3)
-  status: open
+  status: resolved
   **What:** sm-user-plugin 72de822 (in the sm-demo-app submodule checkout
   `plugins/golem15/user`), sm-oauthserver-plugin 2929c91, sm-journal-plugin
   a9a9b80 and sm-demo-app 6fa2d56 add tests only; none is pushed or tagged.
@@ -158,6 +161,11 @@ was changed by the plan that recorded it.
   (sm-user-plugin v0.1.11, sm-oauthserver-plugin v0.1.3, sm-journal-plugin
   v0.2.4) is optional; it would change no shipped code. Push and tags wait
   for the user.
+  **Superseded (19.7-09):** the plugins now also carry the non-test fixes of
+  plan 08 and the tests of plan 09, so the plan 05 test commits ship in the
+  gap-closure plugin tags that require framework v0.5.0; the entries "Demo
+  plugin submodules and pointers wait for the release" and "Release order
+  after the gap closure" below track them.
 - Superuser refusal switch, conditional (found during 19.7-05 Task 4)
   status: open
   **What:** the security review accepted superuser reach through an agent
@@ -166,3 +174,92 @@ was changed by the plan that recorded it.
   destructive backend tool beyond content editing, add the switch (a
   `fix(pier)` with README and docs) and cut a framework patch tag with the
   user's go-ahead.
+- B-IN-05: a prompted record action refused with 422 closes the dialog (found in the code review, deferred by 19.7-07)
+  status: open
+  **What:** when a prompted record action answers 422, the SPA shows the
+  error toast and closes the prompt dialog, so the typed text is lost.
+  Plan 07 corrected the contract text (the 422 toast behaviour is now what
+  the docs and the OpenAPI description say). Keeping the dialog open needs a
+  change to the shared confirm primitive every action uses (the dialog
+  resolves before the request answers), which is out of the gap closure's
+  scope. Follow-up: let the confirm primitive keep the dialog open on a
+  refused submit and show the field error inline.
+- B-IN-06: `window.open` after an awaited POST can be blocked by a popup blocker (found in the code review)
+  status: resolved
+  **What:** no fix required. My account always renders the answered URL as
+  a visible link next to the section (`data-account-contribution-url`), so
+  an administrator whose browser blocked the popup clicks the link
+  (pinned by `admin/tests/account/AccountContributions.test.ts`).
+- `admin:token:revoke` fires no MCP event (found during 19.7-07)
+  status: open
+  **What:** the CLI command revokes an admin personal token's row but does
+  not fire the token-specific `revoked` subject event that the My account
+  revoke fires (`fireTokenRevoked`). The verifier side refuses the revoked
+  token on the next request, so access ends; only a live MCP session of
+  that token keeps its stream until its next request or re-check. Same
+  shape as before plan 07. Fix: call the same helper from the command after
+  its transaction.
+- OIDC grants on a ban or a password reset (decided during 19.7-08)
+  status: resolved
+  **What:** the user decided on 2026-10-23 that a ban, a password reset, an
+  administrator setting a password and the user's own password change end
+  both the MCP and the OIDC grants of the user (tokens revoked, consents
+  and unused codes deleted, subjects kept). Implemented by
+  `Cascade.OnAccessRevoked` (sm-oauthserver-plugin 671513d) and pinned by
+  `TestMCPGrantRevocation` ("access revoked ends earlier MCP and OIDC
+  grants and keeps later ones") and `TestMCPRevocationSmoke`.
+- Local sm-oauthserver-plugin go.work retarget (found during 19.7-08 Task 2)
+  status: open
+  **What:** the tracked `go.work` of sm-oauthserver-plugin is modified in
+  the working tree only: its `sm-user-plugin` replace points at
+  `../sm-demo-app/plugins/golem15/user` (the canonical user checkout of the
+  gap closure) instead of the committed `../fonoteka.go/plugins/golem15/user`.
+  The phase gate's workspace check requires exactly that target, so the
+  gate passes on this machine only with the local edit. Before the release
+  either restore the committed line or decide whether go.work should leave
+  version control; never commit the local retarget.
+- Demo plugin submodules and pointers wait for the release (found during 19.7-08, updated by 19.7-09)
+  status: open
+  **What:** in sm-demo-app the working-tree checkouts of
+  `plugins/golem15/oauthserver` (671513d, its canonical checkout is at
+  65f71dc with plan 09's test), `plugins/golem15/journal` (b129902,
+  canonical at 2aeeccc) and `plugins/golem15/user` (the canonical user
+  checkout itself, 38551a4) are ahead of their committed pins (v0.1.2,
+  v0.2.3, v0.1.10) by unreleased commits. The gate reports them as
+  `pins: … is ahead of its pin by unreleased commits` and refuses them with
+  `PHASE197_RELEASED=1`. The pointers are committed only after the plugin
+  tags. sm-demo-app's `vue-demo-app` pointer is committed (00f57bf, then
+  f53d30a for the link code test): vue-demo-app (0125e29, b973a76) must be
+  pushed before sm-demo-app.
+- Release order after the gap closure (decided 2026-10-23)
+  status: open
+  **What:** nothing of plans 06-09 is tagged or pushed. After the re-review
+  of the gap closure, phase verification, Nyquist validation and UAT pass,
+  and on the user's go-ahead:
+  1. framework v0.5.0 (and the changelog post);
+  2. the sm-user-plugin, sm-oauthserver-plugin and sm-journal-plugin tags
+     that require it;
+  3. the bumps in sm-demo-app, fonoteka.go and sm-bm-app, with vue-demo-app
+     pushed before sm-demo-app;
+  4. sm-servers-app picks up E-1 and E-2 after the user plugin tag;
+  5. then `PHASE197_RELEASED=1 bash scripts/check-phase19.7.sh --consumers`
+     must pass (every demo pin on its tag, no drift).
+- `readLinkCode` accepts a valid code next to other fragment parameters (found during 19.7-09 Task 3)
+  status: open
+  **What:** plan 09 described "extra parameters give ''" for the link page's
+  code reader. `readLinkCode` parses the fragment with URLSearchParams, so
+  `#code=<64 hex>&next=/x` answers the code, while an extended or foreign
+  value (`#code=<hex>x`, `#other=<hex>`) answers ''. `linkCode.test.ts`
+  pins the latter and leaves the former unasserted. My account only ever
+  sends `#code=<code>`, so nothing depends on it; the re-review decides
+  whether to keep the lenient parse or require the fragment to be exactly
+  `code=<64 hex>`.
+- `docs/examples/blog` test failed once on GOPROXY=off (found during 19.7-09 Task 1)
+  status: open
+  **What:** one `go test -short ./...` run of the gate's go stage failed in
+  `docs/examples/blog` with "module lookup disabled by GOPROXY=off" for
+  `golang.org/x/exp`; the package passed alone and in more than twenty later
+  full runs. The test builds a scratch module offline and depends on the
+  module cache holding every dependency; a run that coincides with a cache
+  change may miss one. Not caused by this phase's code; watch for a
+  recurrence.