fix: auth/2FA security — stdout-log code delivery is dev/test-only, production fails closed until email/SMS; verification-code hashing, lockout recovery, sabredav fail-closed

- TWO_FACTOR_ALLOW_LOG_DELIVERY production opt-in REMOVED: plaintext codes are written to the stdout log ([2FA]/[VERIFY]) only in dev/test builds as a local DEV ONLY feature while email/SMS delivery (P6) is implemented. Production builds have no delivery channel and code issuance fails closed (503) under any configuration — no silent log-based code leak
- verification/2FA codes hashed at rest (HMAC-SHA256 via TWO_FACTOR_PEPPER, CHAR(64)); [VERIFY] dev log relay; per-user brute-force budget; password_reset purpose clears lockout for self-service recovery; dummy-bcrypt on login no-user path kills timing oracle
- sabredav weak-password list + entropy gate; .env.example ships fail-closed DAV_ADMIN_PASSWORD
- delete-account re-auth (current_password + fresh 2FA code when enforced)
- prod-tag suite (run-prod-tag-tests.sh) compiles and runs the production 2FA issuance gate: production ALWAYS reports no delivery channel and refuses issuance after the pepper check
- startup_checks_test SNAPSHOT_ENC_KEY values built at runtime so gitleaks sees no secret-shaped literals
- env-docs parity updated (flag removed, 38 vars)

backend/handlers/auth/verifycode_prod.go

@@ -0,0 +1,46 @@
+//go:build !dev && !test
+
+package auth
+
+// Production builds (!dev && !test) of the verification-code flow
+// (POST /api/verify/generate): code issuance fails closed. The stdout-log
+// relay ([VERIFY] prefix) is a DEV/TEST-ONLY local feature — the stand-in for
+// the not-yet-wired email/SMS transport (P6) — and is deliberately never used
+// in a production build:
+//
+//   - a missing TWO_FACTOR_PEPPER: an unsalted SHA-256 digest in the 48-bit
+//     code space would be offline-brute-forceable from a log/DB leak; and
+//   - no delivery channel: there is no production email/SMS transport yet (P6)
+//     and no production opt-in to log delivery, so a minted code could never
+//     reach the user.
+//
+// The plaintext code is therefore never written to the server log in a
+// production build, under any configuration.
+
+import (
+	"errors"
+	"os"
+)
+
+// verificationCodeEnsureIssueAllowed reports whether a verification code may be
+// issued in this deployment. Production requires TWO_FACTOR_PEPPER and, after
+// that, a real delivery channel — which does not exist until email/SMS lands
+// (P6) — so issuance is ALWAYS refused (fail-closed); dev/test builds always
+// allow issuance (verifycode_dev.go).
+func verificationCodeEnsureIssueAllowed() error {
+	if os.Getenv(verificationCodePepperEnv) == "" {
+		return errors.New("verification code issuance requires TWO_FACTOR_PEPPER (an unsalted digest in the 48-bit code space would be offline-brute-forceable); set it in the environment")
+	}
+	return errors.New("verification code issuance requires a delivery channel; email/SMS is not wired yet (P6) — production has no delivery channel until it lands")
+}
+
+// verificationCodeDeliver delivers a fresh verification code to the user.
+// Production: a deliberate no-op — the plaintext code is NEVER written to the
+// server log, so this is unreachable (verificationCodeEnsureIssueAllowed
+// already refused issuance). The dev/test build (verifycode_dev.go) writes the
+// [VERIFY] log line instead — stdout-log delivery is a dev/test-only local
+// feature until email/SMS lands (P6).
+func verificationCodeDeliver(userID, purpose, code string) {
+	// Deliberate no-op: production never logs plaintext codes, under any
+	// configuration. Delivery is dev/test-only until email/SMS lands (P6).
+}