docs/pii.md still describes the auth_user.name conversion as pending

[jakebromberg]

The PII field registry (docs/pii.md, added in #2294) wrote the auth_user.name row in the future tense: classification "Non-PII (post-backfill)", read-sites guidance warning that rows may still hold stale legal-name copies, and enforcement "None yet (Track 2, later PR)".

All of that has since landed:

• The databaseHooks.user derivation hooks shipped in feat(auth): derive auth_user.name from handle/username at a single databaseHooks choke point #2297, with the update-veto corrected to value-keying in fix(auth): veto update-user name writes by value, not key presence #2301.
• jobs/auth-user-name-backfill ran against production on 2026-08-28: 139 of 144 non-anonymous rows rewritten to handle-else-username; the 2 rows whose only legal-name copy lived in name were preserved into real_name first per Track 2a; a post-run dry-run verified idempotence (scanned=144, updated=0).

End state: the registry states the current reality — auth_user.name is Non-PII, readable anywhere, with the hooks + input: false locks + the two wire specs (dj-real-name-sentinel.spec.js, update-user-name-veto.spec.js) named as enforcement — while keeping the note that wxyc/restricted-real-name deliberately does not match bare name.

Files: docs/pii.md only.

Acceptance criteria: no future-tense/pending language remains in the auth_user.name row or the history paragraph; check:doc-rules and format:check stay green.