Fix guest reconnect expiry across database lock waits

[jiashuoz]

Reconnect expiry checks could run before a blocking database lock was acquired. A lock-only transaction could let enrollment or challenge issuance succeed after expiry; a maintenance SHARE table lock could also let final acceptance rotate the bootstrap token and advance the connection epoch after challenge expiry.

Acquire the bootstrap table's ROW EXCLUSIVE lock and the specific bootstrap row lock before checking expiry in all three mutations. Preserve runner → session → bootstrap ordering and the exact identity/attempt/generation acceptance predicates. ROW EXCLUSIVE remains compatible with ordinary concurrent writers. Update the design note to state this requirement.

Validation:

• Six real PostgreSQL cases cover enrollment, challenge issuance, and acceptance under row and table lock contention. The row failures and table issuance/acceptance failures were observed before their fixes; all six pass afterward, including with race instrumentation.
• Refused operations preserve enrollment, pending state, token hash, consumed status, and connection epoch.
• Complete local PostgreSQL-store and application suites pass with -race; CLI race checks, build, and vet also passed during validation.
• Independent and adversarial reviews are clean after addressing the table-lock finding.
• The local full gate encountered Docker credential-helper/registry failures and one latency test that passed in isolation. Final Linux CI passed on a8fc415: full make verify, non-root ownership regression, CLI/client race checks, and fleet-script syntax.

This store path is not yet exposed as an enabled reconnect endpoint. Real PostgreSQL and signed-proof tests exercise the changed surface; the fix does not enable guest reconnect or change a public API. Two commits keep the initial correction and the review-discovered table-lock correction separate.