docs(19.6): v0.1.1 release recorded, finding F-1 deferred

- security review: T-19.6-37 closed by sm-mfa-plugin v0.1.1, F-1 deferred
  with the corrected reason for the activate-by-code mint path
- validation map: plan 04 Tasks 5 and 6 green
- todo for F-1; deferred items: tag message resolved, F-1 deferred

.planning/todos/pending/2026-10-26-activate-by-code-second-factor.md

@@ -0,0 +1,18 @@
+---
+title: activate-by-code mints a session without the second factor when require_activation is off (finding F-1)
+date: 2026-10-26
+priority: low
+area: sm-user-plugin
+---
+
+sm-user-plugin's `POST /_user/api/v1/activate-by-code` signs the account in (`mintFor`) without asking the login gates. Phase 19.6 plan 01 accepted that path because "a new or not-yet-activated account cannot have 2FA yet". That reason holds only with the default `golem15.user.activation.require_activation: true`. With `require_activation: false` and `activate_mode: user`, a not-activated account signs in with its password, can enable TOTP (sm-mfa-plugin), and a later activate-by-code with the mailed activation code answers `{"message":"Account activated","token":…}` with no challenge. The mailbox alone then stands in for the second factor, which a password reset does not allow (a reset mints no token).
+
+Found and reproduced by 19.6-04 (security review finding F-1, 19.6-SECURITY-REVIEW.md "Open findings"): register in mode user, password login, TOTP setup and confirm, the next password login is challenged, `IssueActivationCode`, activate-by-code answers 200 with a token.
+
+The user deferred it at 19.6-04 Task 5 (2026-10-26). Impact is low: it needs the non-default configuration, a user who enabled a second factor before activating, and the user's unexpired activation code.
+
+To fix later:
+- In `ActivateByCode`, after `VerifyActivationCode` succeeds, call `CheckLoginGates` for the user (a source the mfa gate challenges, for example `LoginSourcePassword`, or a new `LoginSourceActivation` together with an sm-mfa-plugin gate change) and answer the gate's body instead of the token; the account stays activated.
+- Add a test in sm-user-plugin (a gate that challenges, then activate-by-code answers the challenge) and an end-to-end case in sm-mfa-plugin's `TestEveryLoginPathIsGated`, and update its `tokenMints` reason.
+- Release sm-user-plugin as a patch and bump sm-demo-app, sm-bm-app and fonoteka.go in separate commits (D-17 order).
+- Until then, `TestEveryLoginPathIsGated/mint_sites` lists `ActivateByCode` with a pointer to F-1, so any change to the mint sites fails until the list is updated.