Recovery-code REST route accepts nonexistent users

Problem

The recovery-code generation REST endpoint does not reject a nonexistent user_id before passing false into provider logic. An authenticated administrator can trigger code generation and warnings for user ID 0; enabling the provider reaches a database failure and returns HTTP 500 instead of a bounded 4xx error.

Minimized reproductions

POST /wp-json/two-factor/1.0/generate-backup-codes

{"user_id":0}

Observed result: HTTP 200 with ten plaintext generated codes plus PHP warnings from providers/class-two-factor-backup-codes.php around lines 332 and 400.

{"user_id":0,"enable_provider":true}

Observed result: HTTP 500 db_error.

Expected

The route should resolve and validate the target user before provider logic or mutations. Missing users should return a stable 404/400 REST error, produce no codes, emit no warnings, and leave all provider state unchanged.

Fuzz evidence

Found during an isolated deterministic multisite REST campaign against #935:

• Seed: 935202607
• 10,000 malformed/schema cases
• 2,000 provider transition sequences
• 14,044 REST operations
• WordPress 6.9, PHP 8.4.21, Two Factor 0.16.0
• user_id=0 cases reproduced deterministically; 14 occurrences generated 28 warnings.

The campaign found no provider-settings/TOTP permission bypass, secret leakage, invariant failure, replay acceptance, or invalid-state mutation.

Start at the POST /wp-json/two-factor/1.0/generate-backup-codes route and inspect providers/class-two-factor-backup-codes.php around lines 332 and 400. Reproduce the user_id=0 cases, then verify that a missing user returns a stable 404/400 error before provider logic or mutations, with no codes, warnings, or provider-state changes.