docs(07): revise plans after checker review

.planning/phases/07-user-plugin-and-authentication/07-05-PLAN.md

@@ -36,6 +36,7 @@ must_haves:
     - "The recorded corpus includes the A2 fixture (6 rapid failed logins) settling whether Winter's throttle actually gates the JWT login path, and the D-12 code-carrying two-step flows (forgot->reset, register->activate-by-code) using a real code read from the target's own database, not a hardcoded value"
     - "No live JWT, inv_ token or database credential is committed to git; the private vars store stays mode 0600 and untracked"
     - "A new nuxt-auth client flow fixture exercises register -> fetch -> update -> change-password -> refresh -> logout -> refused-reuse, plus a must_change_password user reaching 423 then clearing it via change-password after a successful me/locale call (D-14)"
+    - "The 15 new /_user/api/v1 routes are added to fonoteka.go/parity/manifest.yaml (absent from the original 154-route fonoteka manifest), the fixed-154-total wording in parity_test.go/check_corpus.go is corrected to the new total, and no fixture is recorded for a dropped extraction source (query-string/body jwt_token, per D-09), per D-11"
   artifacts:
     - path: "../fonoteka.go/parity/fixtures/nuxt/nuxt-auth.yaml"
       provides: "the D-14 recorded client flow"
@@ -126,7 +127,11 @@ func (s *Store) Expand(text string) (string, error)  // {{name}} substitution us
 
     Create `db_capture.go` (package `main`, alongside the existing `parity_test.go` — or a small standalone `go run`-able file, whichever fits the existing package layout better once read): a helper that, given a target's connection info (the isolated PHP's SQLite path from `$PARITY_ROOT`, or the Go replay target's Postgres DSN) and an email, reads `reset_password_code` or `activation_code` from the `users` row and calls `tide.OpenStore(varsPath)` → `Set("code:reset", value)` or `Set("code:activate", value)` → `Save()`. For the PHP/SQLite side, shell out to `../fonoteka.go/parity/php_parity.sh artisan tinker --execute="echo \Golem15\User\Models\User::where('email','<email>')->value('reset_password_code');"` (avoids adding a new Go SQLite driver dependency for parity-only tooling) and capture stdout. For the Go/Postgres replay side, use the existing `*sql.DB`/DSN the replay harness already opens — a direct `SELECT reset_password_code FROM users WHERE email = $1`. This is the D-12 "app-owned tide seed/capture hook" — it lives in `fonoteka.go/parity`, not in the framework-owned `tide` package, exactly because it knows the Płytarium `users` table shape.
 
-    Record, for EACH of the 15 routes (`login, logout, fetch, refresh, register, forgot-password, reset-password, activate, activate-by-code, update, change-password, avatar, avatar/remove, marketing-consent, oauth-providers`), every distinct status+body PHP actually returns (D-13 — do not assume the bodies drafted during planning are exact; RECORD the real ones and treat any drift as authoritative over the plan text): success case, validation-failure (422) case where applicable, and the specific failure modes named in 07-CONTEXT.md (bad credentials, suspended/banned via the throttle, registration disabled/throttled, bad/expired refresh, wrong current password, expired/invalid reset or activation code). Use `summer parity:record --spec=<one-off YAML per case> --target=http://127.0.0.1:8423 --rules=capture-rules.yaml --vars=<private path> --manifest=manifest.yaml --fixtures=fixtures/routes --next-batch=15 --resume=true` for the bulk of the batch (the whole 15-route surface fits in one `--next-batch=15` call, matching the established 15-route resume workflow), then hand-author additional YAML specs for the extra per-route failure cases and record those individually with `--spec`.
+    Record, for EACH of the 15 routes (`login, logout, fetch, refresh, register, forgot-password, reset-password, activate, activate-by-code, update, change-password, avatar, avatar/remove, marketing-consent, oauth-providers`), every distinct status+body PHP actually returns (D-13 — do not assume the bodies drafted during planning are exact; RECORD the real ones and treat any drift as authoritative over the plan text): success case, validation-failure (422) case where applicable, and the specific failure modes named in 07-CONTEXT.md (bad credentials, suspended/banned via the throttle, registration disabled/throttled, bad/expired refresh, wrong current password, expired/invalid reset or activation code). Every recorded `user` payload (login/fetch/register/update success bodies) MUST include the literal `feedback_widget_hidden: false` key -- if a recorded fixture is missing it, that is a signal the base payload construction in 07-02 needs a follow-up, not that the fixture should be trimmed to match.
+
+    Give two DELIBERATE PHP-quirk reproductions their own named recording pass, since they are easy to silently "fix" during recording if the operator assumes the plan text is wrong instead of PHP: (1) `register()` with `allow_registration=false` or the register throttle tripped, under the pinned `APP_DEBUG=false` -- confirm the recorded body is `{"error":"Internal server error"}`,500, NOT the literal "Registrations are currently disabled."/"Registration is throttled..." text (07-02 Task 3's `SafeExceptionResponse` finding); (2) `POST activate` (authenticated) with a WRONG code -- confirm the recorded body is still 200 `{"user":{...}}` with `is_activated` unchanged, NOT a 422/401 (07-03 Task 1's missing-`if`-guard finding). For both, the RECORDED PHP body is authoritative: if either one comes back looking different from what 07-02/07-03 assumed, that is a real finding to write into this plan's SUMMARY and file as a gap-closure item against the plan that implemented it -- do not silently adjust the fixture to match the plan text's expectation.
+
+    Use `summer parity:record --spec=<one-off YAML per case> --target=http://127.0.0.1:8423 --rules=capture-rules.yaml --vars=<private path> --manifest=manifest.yaml --fixtures=fixtures/routes --next-batch=15 --resume=true` for the bulk of the batch (the whole 15-route surface fits in one `--next-batch=15` call, matching the established 15-route resume workflow), then hand-author additional YAML specs for the extra per-route failure cases and record those individually with `--spec`.
 
     Record the A2 confirmation case explicitly: 6 rapid `POST /_user/api/v1/login` calls with a wrong password for the SAME seeded account, asserting whether the 6th attempt's body differs from attempts 1-5 (settling Assumption A2 — if PHP's `JWTAuth::attempt()` does NOT actually reach Winter's throttle for this route, the 6th attempt's body will be identical to the first; if it does, confirm whatever the actual PHP body is and make sure the Go implementation from 07-02 matches it, filing a gap-closure note in this plan's SUMMARY if a code change is needed).
 
@@ -147,8 +152,10 @@ func (s *Store) Expand(text string) (string, error)  // {{name}} substitution us
     - The A2 fixture (6 rapid failed logins) exists and its 6th-attempt body is explicitly compared against attempt 1 in this plan's SUMMARY
     - `fixtures/nuxt/nuxt-auth.yaml` exists and its steps cover register, fetch, update, change-password, refresh, logout, and a refused token-reuse step
     - `parity_test.go`'s `expectedPHPRoutes` reads `169`
+    - The recorded `register` disabled/throttled fixture body is `{"error":"Internal server error"}`,500 under `APP_DEBUG=false`, and the recorded authenticated `activate`-with-wrong-code fixture body is 200 `{"user":{...}}` with `is_activated` unchanged -- both named explicitly in this plan's SUMMARY as confirmed, not assumed
+    - Every recorded login/fetch/register/update success fixture's `user` payload contains the literal key `feedback_widget_hidden: false`
   </acceptance_criteria>
-  <done>15 new manifest entries exist with D-13-complete case coverage; the A2 and D-12 cases are recorded and settled; nuxt-auth.yaml exists and records the full D-14 sequence.</done>
+  <done>15 new manifest entries exist with D-13-complete case coverage; the A2 and D-12 cases are recorded and settled; nuxt-auth.yaml exists and records the full D-14 sequence; both named PHP-quirk reproductions (register disabled/throttled degrading to 500, authenticated activate's no-op-on-wrong-code) are confirmed against the real recorded PHP body.</done>
 </task>
 
 <task type="checkpoint:human-verify" gate="blocking">
@@ -156,7 +163,7 @@ func (s *Store) Expand(text string) (string, error)  // {{name}} substitution us
   <files>../fonoteka.go/parity/fixtures/routes, ../fonoteka.go/parity/fixtures/nuxt/nuxt-auth.yaml, ../fonoteka.go/parity/manifest.yaml</files>
   <read_first>the fixture files Task 2 recorded, ../fonoteka.go/parity/manifest.yaml</read_first>
   <action>
-    Confirm via `git status` over `fonoteka.go/parity/` that the private vars store path is NOT staged (it should sit outside the repo or be gitignored, mode 0600, per the established Phase 2 convention). Grep the new fixtures for live JWT/`inv_` token shapes (a capture leak `tide`'s masking should already prevent, verified directly here since these are brand-new files). Run the corpus and replay commands below. Spot-check 2-3 fixture bodies against this plan's D-13 expectations (e.g. the login-failure body, the change-password wrong-current-password body) to confirm the recorded PHP behavior matches what 07-02/07-03 implemented -- flag any drift for a gap-closure note rather than silently accepting a mismatch.
+    Confirm via `git status` over `fonoteka.go/parity/` that the private vars store path is NOT staged (it should sit outside the repo or be gitignored, mode 0600, per the established Phase 2 convention). Grep the new fixtures for live JWT/`inv_` token shapes (a capture leak `tide`'s masking should already prevent, verified directly here since these are brand-new files). Run the corpus and replay commands below. Spot-check 2-3 fixture bodies against this plan's D-13 expectations (e.g. the login-failure body, the change-password wrong-current-password body) to confirm the recorded PHP behavior matches what 07-02/07-03 implemented -- flag any drift for a gap-closure note rather than silently accepting a mismatch. Specifically re-confirm Task 2's two named PHP-quirk recordings here as part of the sign-off: the register disabled/throttled fixture reads `{"error":"Internal server error"}`,500 (not the literal disabled/throttled text), and the authenticated activate-with-wrong-code fixture reads 200 `{"user":{...}}` (not a 4xx) -- both are deliberate reproductions of PHP quirks read directly from source in 07-02/07-03, not planning guesses, so the recorded body is authoritative if either differs from what is written here.
   </action>
   <verify>
     <automated>! grep -rE "eyJ[A-Za-z0-9_-]+[.][A-Za-z0-9_-]+[.][A-Za-z0-9_-]+|inv_[A-Za-z0-9]{8,}" ../fonoteka.go/parity/fixtures/routes/*user_api_v1* ../fonoteka.go/parity/fixtures/nuxt/nuxt-auth.yaml && go test ./parity/... -run TestParityCorpus -v</automated>
@@ -169,8 +176,9 @@ func (s *Store) Expand(text string) (string, error)  // {{name}} substitution us
     - The JWT/`inv_`-shape grep over the new fixtures returns zero matches
     - `git status` does not list the private vars store path
     - `go test ./parity/... -run TestParityCorpus -v` reports zero failing cases among the newly ported routes
+    - The two named PHP-quirk fixtures (register disabled/throttled -> 500 opaque body; authenticated activate-with-wrong-code -> 200 unchanged) are explicitly re-confirmed in this task's sign-off, with any drift noted as a gap-closure item rather than silently accepted
   </acceptance_criteria>
-  <done>No live JWT/inv_ token shape is present in any committed fixture; the private vars store is untracked and 0600; TestParityCorpus and summer parity:replay are green for every newly ported route.</done>
+  <done>No live JWT/inv_ token shape is present in any committed fixture; the private vars store is untracked and 0600; TestParityCorpus and summer parity:replay are green for every newly ported route; both named PHP-quirk reproductions are confirmed against the real recorded PHP body.</done>
 </task>
 
 </tasks>