Summary

Fixes #66171

Passwordless token-auth Matrix bots fail to complete E2EE bootstrap when the homeserver has existing SSSS data but the bot has no local recovery key.

Problem Statement

Two independent bugs in extensions/matrix/src/matrix/sdk.ts combine to permanently block E2EE bootstrap for passwordless token-auth bots connecting to a homeserver with existing (but inaccessible) SSSS:

Bug 1: MATRIX_INITIAL_CRYPTO_BOOTSTRAP_OPTIONS (line 140) is missing allowSecretStorageRecreateWithoutRecoveryKey: true. Without this flag, when bootstrapCrossSigning encounters a null getSecretStorageKey response (because the bot has no local recovery key), shouldRepairSecretStorage evaluates to false && true = false, so SSSS is never recreated. The explicit bootstrap path (bootstrapOwnDeviceVerification) already sets this flag correctly — the initial auto-startup path does not.

Bug 2: bootstrapCryptoIfNeeded repair path (line ~609) is gated behind this.password?.trim(). Passwordless token-auth bots have no password, so even if Bug 1 were fixed, the repair bootstrap would never run. The intent of the gate was to ensure a UIA credential was available — but UIA failures are already caught and logged gracefully in the existing try/catch, so the gate is overly conservative.

Solution Approach Applied

Two minimal edits to extensions/matrix/src/matrix/sdk.ts:

Edit 1 — Add flag to initial bootstrap options (~line 140):

const MATRIX_INITIAL_CRYPTO_BOOTSTRAP_OPTIONS = {
  allowAutomaticCrossSigningReset: false,
  allowSecretStorageRecreateWithoutRecoveryKey: true,  // added
} satisfies MatrixCryptoBootstrapOptions;

Edit 2 — Remove password gate in repair path (~line 609):
Replace else if (this.password?.trim()) { ... } else { LogService.warn(...) } with a plain else { ... } — the try/catch body stays identical, only the gate is removed. Added comment explaining passwordless repair intent to prevent regression.

Test updates in extensions/matrix/src/matrix/sdk.test.ts:

• Line 1283: Update initial bootstrap options assertion to include new flag
• Lines 1287-1324: Update test to assert repair runs without password (was asserting repair does NOT run)
• Lines 1326-1358: New regression test verifying repair catches UIA failure without throwing

Bottleneck Solved

Before: Fresh bot / bot with wiped data directory connecting to homeserver that has existing SSSS → getSecretStorageKey returns null → error silently swallowed → no repair attempted → bot stays unverified forever.

After: Same scenario → getSecretStorageKey returns null → repair bootstrap runs → SSSS recreated with new keys → bot becomes verified.

Expected Outcomes

• Passwordless token-auth bots can complete E2EE bootstrap on first connection to homeserver with existing SSSS
• Bots with wiped data directories can recover by recreating SSSS
• UIA failures (when homeserver requires password but bot has none) are caught and logged as warnings, not fatal errors
• No behavior change for bots with passwords or explicit bootstrap flows

Current Flow

1. Bot connects to homeserver with encryption enabled
2. Initial bootstrap runs with MATRIX_INITIAL_CRYPTO_BOOTSTRAP_OPTIONS (now includes allowSecretStorageRecreateWithoutRecoveryKey: true)
3. If getSecretStorageKey returns null, bootstrapCrossSigning recreates SSSS
4. If initial bootstrap incomplete and device not owner-signed, repair bootstrap runs (no password gate)
5. Repair bootstrap attempts SSSS recreation with MATRIX_AUTOMATIC_REPAIR_BOOTSTRAP_OPTIONS
6. UIA failures caught and logged, bot continues operating

Verification

pnpm build passes (TypeScript compilation confirms types are correct).

Full test suite not run in this PR (monorepo tests take 10+ min). CI will verify.