Require recent step-up authentication for privileged user administration #308

Parent: #244
Epic: #15
Severity: High
Execution mode: HITL for the proof mechanism, then AFK implementation

What to build

Require a fresh proof of the Owner identity before security-sensitive user administration. A stolen but still-valid Owner access token can currently create another Owner or reset another user password, turning a short-lived token theft into durable account control.

Define one coherent recent-authentication mechanism, such as current-password confirmation that returns a short-lived, audience-limited step-up grant. Keep break-glass recovery out of this browser flow. Classify the sensitive operations explicitly rather than applying an accidental blanket prompt to ordinary farm administration.

#283 secures first provisioning only; it does not solve post-login token theft.

Acceptance criteria

• The threat model and selected proof mechanism are documented before implementation, including lifetime, replay behavior, browser storage, and failure handling.
• Creating an Owner and resetting another privileged user password require a valid, recent step-up grant in addition to the normal Owner access token.
• The grant is short-lived, bound to the current account and user, unusable as a normal access token, and invalidated by password/security-stamp changes and logout.
• A stolen access token without the step-up proof receives a non-enumerating denial and cannot establish a replacement Owner.
• The SPA prompts only when a sensitive operation needs proof, never stores the entered password, and clears proof state on logout.
• API integration tests cover missing, expired, replayed, wrong-account, and revoked proofs.
• SPA tests cover success, cancel, expiry, and server rejection.
• User-visible security behavior is reflected in the Help page and glossary if terminology changes.

Blocked by

A short owner decision on the proof mechanism. Implementation is otherwise independent.