T10.3 D13 - drop users.password_hash and every path that touched it

The irreversible one. The suite no longer stores a credential of any kind.

Removed from app.py: /api/auth/forgot-password, /api/auth/reset-password,
/api/auth/reset-available, /api/auth/password, /api/auth/users/{id}/password,
the four password-bearing input models, the reset throttle and mail body, and
the password arguments to create_user. Removed from auth.py: hash_password,
verify_password, password_problem, MIN_PASSWORD_LEN, _COMMON_PASSWORDS,
create_reset_token, decode_reset_token, RESET_MINUTES, and the bcrypt import.
Removed from notify.py: the password_reset_enabled feature flag. Removed from
manage_users.py: the password prompt and the reset-password command.

token_version STAYS. Password changes no longer exist, but a role change or a
deactivation still has to invalidate sessions that are already issued.

/api/auth/users/{id}/role stays, which is D13 criterion 4 - granting admin to
an existing account must keep working, and it does.

Migration b7e4f1a20c93 uses batch_alter_table because SQLite has no DROP COLUMN
before 3.35 and local dev runs on SQLite while production runs on Postgres.
downgrade() recreates the column NULLABLE rather than NOT NULL as the baseline
declared it: there are no hashes to put back, and a NOT NULL column with no
server default refuses to add itself to a table with rows. The docstring says
plainly that the downgrade does not restore the old login - it exists so the
revision is well-formed, not because stepping back is a recovery path.

Verified:

  upgrade head from empty      -> password_hash absent from users
  downgrade -1                 -> column back, nullable (notnull=0)
  upgrade head again           -> absent again
  remaining /api/auth routes   -> no password or reset route left
  create-admin                 -> works with no password prompt
  grep for the removed symbols -> nothing outside the migration and one
                                  docstring that names the dropped column

NOT verified, and it is a done-when box left open rather than ticked: the
migration has only been round-tripped on SQLite. No Postgres is available here.
batch_alter_table takes the direct ALTER path on Postgres, which is the simpler
of the two, but "simpler" is not "tested".

notify.send_now is now orphaned - its only caller was forgot_password. Logged as
BL-026 rather than deleted in passing, because an immediate unqueued send is a
reasonable primitive to keep and that decision does not belong in an auth task.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/waves/backlog.md

@@ -554,3 +554,21 @@ deliberately deferred.
   entry rather than a drive-by.
 - **Suggested wave or follow-up:** next housekeeping pass, with the check
   widened so it cannot recur.
+
+### BL-026 — `notify.send_now` is orphaned once D13 removes password reset
+
+- **Found during:** `T10.3` (D13), stripping the password code paths
+- **Where:** `server/notify.py`, `send_now()`
+- **What:** `send_now` sends one message immediately, outside the outbox queue. Its
+  only caller was `forgot_password`, because a reset link must not sit in a queue.
+  `T10.3` deleted that endpoint, so the function now has no callers anywhere in
+  `server/` or `tests/` — verified by grep, not assumed.
+- **Why not now:** deleting it is a drive-by CLAUDE.md forbids, and it is not
+  obviously dead weight: an immediate, unqueued send is the right primitive for any
+  future time-sensitive mail, and the queue is the wrong shape for that. Deciding
+  between "delete it" and "keep it as the documented immediate-send path" is a
+  judgement call that deserves its own entry rather than being settled inside an
+  auth task.
+- **Suggested wave or follow-up:** next housekeeping pass. If kept, its docstring
+  needs rewriting — it currently explains itself in terms of password resets, which
+  no longer exist.