switchroom 0.7.15 → 0.10.0

package/telegram-plugin/uat/scenarios/vault-approval-posture-telegram-id-dm.test.ts

@@ -0,0 +1,191 @@
+/**
+ * UAT scenario for #1115 — `vault.broker.approvalAuth: telegram-id`
+ * single-factor approve path.
+ *
+ * **What this exercises that unit tests cannot.** The schema test, the
+ * resolver fuzz, and the source-text contracts all live inside the
+ * gateway process. They prove the wiring is shaped right. They do NOT
+ * prove that:
+ *   - the *live* Telegram callback for the Approve button is routed
+ *     to `handleVaultRequestAccessCallback`,
+ *   - the gateway-cached `AUTO_UNLOCK_PASSPHRASE` is what the broker
+ *     actually accepts,
+ *   - the broker mints a real grant token end-to-end with no
+ *     passphrase prompt visible in chat,
+ *   - the success card carries the single-factor footer
+ *     (`Approver verified by Telegram identity`).
+ *
+ * This scenario closes that gap by round-tripping a real Telegram tap
+ * against a real broker on a host configured with
+ * `vault.broker.approvalAuth: telegram-id`.
+ *
+ * Sibling: `vault-request-access-end-to-end-dm.test.ts` exercises the
+ * same agent-initiated path under the DEFAULT `passphrase` posture
+ * (two-factor). The two scenarios together pin both rungs of the
+ * posture matrix.
+ *
+ * **Skipped by default.** To unskip:
+ *
+ * 1. Standard UAT preflight (`uat/SETUP.md` §5-6) — test-harness agent
+ *    live, driver session auth'd, env vars set.
+ *
+ * 2. **Host posture flipped to single-factor.** Edit `switchroom.yaml`:
+ *
+ *      vault:
+ *        broker:
+ *          autoUnlock: true
+ *          approvalAuth: telegram-id
+ *
+ *    Then `switchroom update` (or `apply` + restart gateway). The
+ *    scenario refuses to run if `switchroom doctor` reports the
+ *    passphrase posture — running it under passphrase mode would
+ *    block on a passphrase prompt the scenario doesn't send.
+ *
+ * 3. **Sacrificial vault key.** Same convention as the sibling:
+ *
+ *      TMPF=$(mktemp) && printf '%s' 'sentinel-1115-value' > "$TMPF" && \
+ *        switchroom vault set uat/req-access-target-tid --file "$TMPF" \
+ *          --format string ; shred -u "$TMPF"
+ *
+ * 4. Remove `describe.skip` below.
+ *
+ * Why skipped: (a) mutates host vault state (mints a 30-day grant on
+ * test-harness), (b) requires the operator to flip the live posture
+ * — opt-in only. Cleanup is operator-side
+ * (`switchroom vault revoke <grant-id>` after the run, then revert
+ * the posture if desired).
+ */
+
+import { describe, expect, it } from "vitest";
+import { spinUp } from "../harness.js";
+
+const SENTINEL_VALUE = "sentinel-1115-value";
+const TARGET_KEY = "uat/req-access-target-tid";
+
+describe.skip("uat: vault_request_access — telegram-id (single-factor) posture (#1115)", () => {
+  it(
+    "agent calls tool → operator taps Approve → silent mint, no passphrase prompt, single-factor footer present",
+    async () => {
+      const sc = await spinUp({ agent: "test-harness" });
+      try {
+        // 1. Trigger the agent-side MCP tool call. The agent's reply
+        //    is what emits the approval card.
+        await sc.sendDM(
+          `Please call your vault_request_access MCP tool with ` +
+          `key="${TARGET_KEY}", scope="read", reason="UAT regression for #1115 ` +
+          `(telegram-id single-factor posture)". Then attempt to read the key ` +
+          `once the operator confirms.`,
+        );
+
+        // 2. Wait for the bot's approval card. Anchor on the headline
+        //    emoji + tool-specific copy — same as the passphrase
+        //    sibling scenario, since the card itself is identical
+        //    regardless of posture (it's the Approve-tap behaviour
+        //    that diverges).
+        const card = await sc.expectMessage(/🔐.*wants vault access/, {
+          from: "bot",
+          timeout: 60_000,
+        });
+
+        // 3. Confirm the inline keyboard has the Approve button and
+        //    locate its callback_data.
+        const kb = await sc.driver.getKeyboard(sc.botUserId, card.messageId);
+        expect(kb).not.toBeNull();
+        const approveButton = kb!
+          .flat()
+          .find((b) => b.callbackData !== undefined && /approve/i.test(b.text));
+        expect(approveButton, "card should have an [✅ Approve] button").toBeDefined();
+
+        // 4. Tap Approve. Under `telegram-id` posture this MUST take
+        //    us straight to the "Approved by @ … — minting…" state —
+        //    no passphrase prompt should appear at any point.
+        await sc.driver.pressButton(
+          sc.botUserId,
+          card.messageId,
+          approveButton!.callbackData!,
+        );
+
+        // 5. Expect the immediate "minting" edit (with operator
+        //    @username) — the load-bearing UX signal that the
+        //    passphrase prompt was skipped.
+        await sc.expectMessage(/Approved by @.*minting/i, {
+          from: "bot",
+          timeout: 15_000,
+        });
+
+        // 6. Expect the success card with the SINGLE-FACTOR footer —
+        //    `performVaultAccessApproval` annotates the card with
+        //    "Approver verified by Telegram identity (broker
+        //    auto-unlocked at startup)" only under telegram-id mode.
+        //    If posture flipped silently to passphrase between steps
+        //    1 and 5, the footer wouldn't say this and the regex
+        //    misses → the scenario fails with a posture-state
+        //    diagnosis.
+        const granted = await sc.expectMessage(
+          /Granted.*read access[\s\S]*Approver verified by Telegram identity/i,
+          { from: "bot", timeout: 30_000 },
+        );
+        expect(granted.text).toMatch(/broker auto-unlocked at startup/i);
+
+        // 7. **Negative invariant** — *implicit*. The scenario sends
+        //    no passphrase between steps 4 (tap) and 6 (Granted). If
+        //    the gateway had actually fallen back to the passphrase
+        //    branch (`Reply with your passphrase` prompt), the flow
+        //    would stall waiting for an operator reply and the
+        //    `expectMessage(/Granted .../)` in step 6 would time out.
+        //    The single-factor-footer regex in step 6 is the
+        //    explicit positive gate that we landed in the
+        //    telegram-id branch and not, say, an unlocked-cache
+        //    shortcut.
+
+        // 8. Load-bearing functional assertion: the freshly-minted
+        //    grant actually works. Mirrors the sibling scenario's
+        //    final assertion so a future regression that breaks
+        //    the token-write path is caught here too.
+        await sc.sendDM(
+          `Now run: switchroom vault get ${TARGET_KEY} — and tell me ` +
+          `exactly what the command printed (including any error markers).`,
+        );
+        const replyAfterGet = await sc.expectMessage(
+          new RegExp(SENTINEL_VALUE),
+          { from: "bot", timeout: 60_000 },
+        );
+        expect(replyAfterGet.text).toContain(SENTINEL_VALUE);
+        expect(replyAfterGet.text).not.toMatch(/VAULT-BROKER-DENIED/);
+      } finally {
+        await sc.tearDown();
+      }
+    },
+    300_000,
+  );
+
+  it(
+    "doctor reports the single-factor posture so operators can verify the host before merging",
+    async () => {
+      // This second-tier check exists to flush out the failure mode
+      // where the YAML lands `approvalAuth: telegram-id` but the
+      // gateway either didn't reload or the schema-validation gate
+      // silently rejected it. Without this check, scenario 1 still
+      // passes when the gateway has reverted to passphrase posture
+      // (the operator would just be looking at a separate gateway
+      // process state and we'd never know).
+      const sc = await spinUp({ agent: "test-harness" });
+      try {
+        await sc.sendDM(
+          `Run: switchroom doctor — and quote exactly the line containing ` +
+          `"Approval auth:".`,
+        );
+        const doctorReply = await sc.expectMessage(
+          /Approval auth:\s*telegram-id/i,
+          { from: "bot", timeout: 60_000 },
+        );
+        expect(doctorReply.text).toMatch(
+          /single-factor.*Telegram account security/i,
+        );
+      } finally {
+        await sc.tearDown();
+      }
+    },
+    120_000,
+  );
+});

package/telegram-plugin/uat/scenarios/vault-audit-allow-dm.test.ts

@@ -0,0 +1,108 @@
+/**
+ * Vault UX scenario — operator DMs `/vault audit`, taps `[Allow]`
+ * on a recent denial, agent re-attempts the vault read and succeeds.
+ *
+ * Part of: https://github.com/switchroom/switchroom/issues/866
+ * Exercises: #969 P2b one-tap allow flow.
+ *
+ * **Gated by operator setup.** To unskip:
+ *
+ * 1. **Driver must be admin on `test-harness`.** `agent add
+ *    --allow-from $DRIVER_UID` already includes the driver in
+ *    `access.json:allowFrom`. Confirm the `/vault` commands also
+ *    work — they may require an explicit `admin_chat_id` setting
+ *    in the agent's switchroom.yaml. Look for
+ *    "VAULT-AUDIT-FORBIDDEN" or similar in the gateway log when
+ *    the driver DMs `/vault audit`.
+ *
+ * 2. **Sacrificial vault keys for the test.** The scenario writes
+ *    and reads `uat-test-denial` under a deliberately empty
+ *    `--allow` scope so the agent's first read fails with
+ *    VAULT-BROKER-DENIED — that denial is what shows up in
+ *    `/vault audit`. Pre-create the key on the host:
+ *
+ *    ```bash
+ *    TMPF=$(mktemp) && printf '%s' 'sentinel-uat-value' > "$TMPF" && \
+ *      switchroom vault set uat-test-denial --file "$TMPF" \
+ *        --format string ; shred -u "$TMPF"
+ *    ```
+ *
+ *    The scenario then triggers a denial, taps Allow (scopes the
+ *    key to `test-harness`), and asserts the agent can now read it.
+ *    Cleanup at the end is operator-side: re-narrow the scope or
+ *    remove the key.
+ *
+ * 3. Remove the `describe.skip` below.
+ *
+ * Why skipped by default: the scenario mutates host vault state
+ * (broker ACL) — opt-in only.
+ */
+
+import { describe, expect, it } from "vitest";
+import { spinUp } from "../harness.js";
+
+describe.skip("uat: /vault audit one-tap allow", () => {
+  it("driver taps [Allow] on a recent denial; agent's next read succeeds", async () => {
+    const sc = await spinUp({ agent: "test-harness" });
+    try {
+      // 1. Trigger a denial by asking the agent to read a key the
+      //    agent isn't yet scoped for.
+      await sc.sendDM(
+        "Please run `switchroom vault get uat-test-denial` and tell me the value.",
+      );
+
+      // The bot's denial trace finishes the turn — wait for the
+      // turn-end message, then proceed to /vault audit.
+      await sc.expectMessage(/VAULT-BROKER-DENIED|denied|cannot/i, {
+        from: "bot",
+        timeout: 60_000,
+      });
+
+      // 2. DM /vault audit. The bot replies with a recent-denials
+      //    summary + inline [Allow] / [Deny] buttons per denied key.
+      await sc.sendDM("/vault audit");
+      const auditCard = await sc.expectMessage(/Recent denials|uat-test-denial/, {
+        from: "bot",
+        timeout: 30_000,
+      });
+
+      // 3. Find and press the [Allow] button.
+      const kb = await sc.driver.getKeyboard(sc.botUserId, auditCard.messageId);
+      expect(kb).not.toBeNull();
+      const allowButton = kb!
+        .flat()
+        .find(
+          (b) =>
+            b.callbackData !== undefined &&
+            /allow/i.test(b.text) &&
+            b.callbackData.includes("uat-test-denial"),
+        );
+      expect(allowButton).toBeDefined();
+      await sc.driver.pressButton(
+        sc.botUserId,
+        auditCard.messageId,
+        allowButton!.callbackData!,
+      );
+
+      // 4. Confirmation comes back via card edit; assert it lands.
+      //    (The gateway typically edits the audit card in-place to
+      //    show "allowed" status.)
+      await sc.expectMessage(/allowed|✓|scope updated/i, {
+        from: "bot",
+        timeout: 15_000,
+      });
+
+      // 5. Re-attempt the read. Should now succeed.
+      await sc.sendDM(
+        "Try `switchroom vault get uat-test-denial` again now.",
+      );
+      const success = await sc.expectMessage(/sentinel-uat-value/, {
+        from: "bot",
+        timeout: 60_000,
+      });
+      expect(success.text).toContain("sentinel-uat-value");
+    } finally {
+      await sc.tearDown();
+    }
+  });
+});

package/telegram-plugin/uat/scenarios/vault-grant-auto-resume-dm.test.ts

@@ -0,0 +1,121 @@
+/**
+ * End-to-end UAT scenario for #1052 — agent auto-resumes its task
+ * after operator approves a vault_request_access card.
+ *
+ * Pre-fix: agent fired vault_request_access → ended its turn → operator
+ * approved later → grant minted → agent did nothing further until
+ * operator messaged again. Operator had to manually nudge the agent
+ * to resume work the agent itself had flagged.
+ *
+ * Fix: gateway injects a synthetic InboundMessage after successful
+ * mint (via the existing inject_inbound IPC primitive cron uses).
+ * Agent's bridge receives the channel event, starts a new turn, and
+ * resumes the task.
+ *
+ * Load-bearing assertion: after the operator's passphrase reply +
+ * "Granted" card edit, the DRIVER sees a NEW bot turn (a substantive
+ * reply that uses the just-granted key) WITHOUT the driver sending
+ * any further message.
+ *
+ * **Skipped by default.** To unskip:
+ *
+ * 1. Standard UAT preflight (`uat/SETUP.md` §5-6).
+ * 2. `TELEGRAM_UAT_VAULT_PASSPHRASE` set in env.
+ * 3. Pre-create a sacrificial vault key:
+ *
+ *    ```bash
+ *    TMPF=$(mktemp) && printf '%s' 'sentinel-1052-value' > "$TMPF" && \
+ *      switchroom vault set uat/auto-resume-key --file "$TMPF" \
+ *        --format string ; shred -u "$TMPF"
+ *    ```
+ *
+ * 4. Remove `describe.skip` below.
+ *
+ * Why skipped: mutates vault state. Cleanup is operator-side post-run.
+ */
+
+import { describe, expect, it } from "vitest";
+import { spinUp } from "../harness.js";
+
+const KEY = "uat/auto-resume-key";
+const SENTINEL = "sentinel-1052-value";
+
+describe.skip("uat: agent auto-resumes after vault grant approval (#1052)", () => {
+  it(
+    "agent fires card, operator approves, agent emits new turn WITHOUT a nudge",
+    async () => {
+      const passphrase = process.env.TELEGRAM_UAT_VAULT_PASSPHRASE;
+      if (!passphrase) {
+        throw new Error(
+          "TELEGRAM_UAT_VAULT_PASSPHRASE must be set in env (see uat/SETUP.md).",
+        );
+      }
+      const sc = await spinUp({ agent: "test-harness" });
+      try {
+        // 1. Ask the agent to fetch the key — it'll hit DENIED first,
+        //    fire vault_request_access, then end its turn.
+        await sc.sendDM(
+          `Please run \`switchroom vault get ${KEY}\`. If you get ` +
+          `VAULT-BROKER-DENIED, call your vault_request_access MCP tool ` +
+          `for that key (read, 30d, reason "UAT for #1052 auto-resume"), ` +
+          `END YOUR TURN cleanly, and when the operator approves you should ` +
+          `automatically resume by re-running the vault get and reporting ` +
+          `the value.`,
+        );
+
+        // 2. Wait for the approval card.
+        const card = await sc.expectMessage(/🔐.*wants vault access/, {
+          from: "bot",
+          timeout: 120_000,
+        });
+        const kb = await sc.driver.getKeyboard(sc.botUserId, card.messageId);
+        const approveButton = kb!
+          .flat()
+          .find((b) => b.callbackData !== undefined && /approve/i.test(b.text));
+        expect(approveButton).toBeDefined();
+
+        // 3. Tap Approve. Triggers passphrase prompt.
+        await sc.driver.pressButton(sc.botUserId, card.messageId, approveButton!.callbackData!);
+        await sc.expectMessage(/Vault is locked.*Reply with your passphrase/, {
+          from: "bot",
+          timeout: 15_000,
+        });
+
+        // 4. Send passphrase. Card edits to "Granted ...".
+        const lastDriverMsg = await sc.sendDM(passphrase);
+        const lastDriverMsgId = lastDriverMsg.messageId;
+        await sc.expectMessage(/Granted.*read access/, {
+          from: "bot",
+          timeout: 30_000,
+        });
+
+        // 5. THE LOAD-BEARING #1052 ASSERTION: the agent should
+        //    auto-resume WITHOUT the driver sending another message.
+        //    We wait for a substantive bot reply containing the
+        //    sentinel value, OR matching the auto-resume channel
+        //    source marker the gateway stamps.
+        //
+        //    Pre-fix: this assertion times out (no synthetic
+        //    injection → agent's bridge never received a new turn
+        //    → agent stayed idle).
+        //
+        //    Post-fix: the gateway's ipcServer.sendToAgent fires a
+        //    synthetic inbound with meta.source="vault_grant_approved".
+        //    The agent's bridge starts a new turn, re-runs vault get,
+        //    and reports the value.
+        const autoResumeReply = await sc.expectMessage(
+          new RegExp(SENTINEL),
+          { from: "bot", timeout: 180_000 },
+        );
+        expect(autoResumeReply.text).toContain(SENTINEL);
+        expect(
+          autoResumeReply.messageId,
+          "auto-resume reply must be a NEW message, not the granted-card edit",
+        ).toBeGreaterThan(lastDriverMsgId);
+      } finally {
+        await sc.tearDown();
+      }
+    },
+    420_000,
+  );
+});

package/telegram-plugin/uat/scenarios/vault-request-access-concurrent-dm.test.ts

@@ -0,0 +1,161 @@
+/**
+ * End-to-end UAT scenario for the #1051 fix — concurrent
+ * vault_request_access cards must BOTH end up readable by the agent.
+ *
+ * #1051 had two failure modes:
+ *   (a) `.vault-token` overwrite — each new grant strands the prior
+ *       (agent can read only the most-recently-approved key).
+ *   (b) pending-op race — second Approve tap before first passphrase
+ *       reply orphans the first stage entirely (no second grant
+ *       even minted).
+ *
+ * Both fixed by the gateway-side grant-union path: list existing
+ * grants → union keys → mint a consolidated grant. PLUS the
+ * pending-op shape extended to a queue so concurrent taps don't
+ * overwrite.
+ *
+ * This scenario covers (a) — the most-likely real-world repro
+ * (gymbro fires two cards back-to-back; operator approves both
+ * sequentially). Covering (b) cleanly needs precise tap-timing
+ * that's harder to script — the static-source test
+ * `telegram-plugin/tests/vault-grant-union.test.ts` pins it at the
+ * code level instead.
+ *
+ * **Skipped by default.** To unskip:
+ *
+ * 1. Standard UAT preflight (`uat/SETUP.md` §5-6).
+ * 2. `TELEGRAM_UAT_VAULT_PASSPHRASE` set in env.
+ * 3. Pre-create two sacrificial vault keys:
+ *
+ *    ```bash
+ *    for k in uat/concurrent-a uat/concurrent-b ; do
+ *      TMPF=$(mktemp); printf '%s' "sentinel-$(basename "$k")" > "$TMPF"
+ *      switchroom vault set "$k" --file "$TMPF" --format string
+ *      shred -u "$TMPF"
+ *    done
+ *    ```
+ *
+ * 4. Remove `describe.skip` below.
+ *
+ * Why skipped: mutates vault state (mints a grant covering both keys
+ * on test-harness). Cleanup is operator-side post-run.
+ */
+
+import { describe, expect, it } from "vitest";
+import { spinUp } from "../harness.js";
+
+const KEY_A = "uat/concurrent-a";
+const KEY_B = "uat/concurrent-b";
+const SENTINEL_A = "sentinel-concurrent-a";
+const SENTINEL_B = "sentinel-concurrent-b";
+
+describe.skip("uat: concurrent vault_request_access approvals — both grants survive (#1051)", () => {
+  it(
+    "agent fires two cards back-to-back, operator approves both → agent can read both keys",
+    async () => {
+      const passphrase = process.env.TELEGRAM_UAT_VAULT_PASSPHRASE;
+      if (!passphrase) {
+        throw new Error(
+          "TELEGRAM_UAT_VAULT_PASSPHRASE must be set in env (see uat/SETUP.md).",
+        );
+      }
+      const sc = await spinUp({ agent: "test-harness" });
+      try {
+        // 1. Tell the agent to fire TWO vault_request_access calls
+        //    in the same turn for two distinct keys. The natural way
+        //    to express this is one prompt that describes both
+        //    needs; the agent then makes both tool calls.
+        await sc.sendDM(
+          `Please call your vault_request_access MCP tool TWICE — ` +
+          `once for key="${KEY_A}" and once for key="${KEY_B}" — ` +
+          `both scope="read", both reason="UAT for #1051 concurrent". ` +
+          `Then attempt to read BOTH keys via switchroom vault get and ` +
+          `print the values in your reply.`,
+        );
+
+        // 2. Wait for the FIRST approval card.
+        const cardA = await sc.expectMessage(
+          new RegExp(`🔐.*wants vault access[\\s\\S]*${KEY_A.replace("/", "\\/")}`),
+          { from: "bot", timeout: 90_000 },
+        );
+        const cardB = await sc.expectMessage(
+          new RegExp(`🔐.*wants vault access[\\s\\S]*${KEY_B.replace("/", "\\/")}`),
+          { from: "bot", timeout: 30_000 },
+        );
+
+        // 3. Tap Approve on card A.
+        const kbA = await sc.driver.getKeyboard(sc.botUserId, cardA.messageId);
+        const approveA = kbA!
+          .flat()
+          .find((b) => b.callbackData !== undefined && /approve/i.test(b.text));
+        expect(approveA).toBeDefined();
+        await sc.driver.pressButton(sc.botUserId, cardA.messageId, approveA!.callbackData!);
+
+        // Wait for the passphrase prompt on card A.
+        await sc.expectMessage(/Vault is locked.*Reply with your passphrase/, {
+          from: "bot",
+          timeout: 15_000,
+        });
+
+        // 4. Tap Approve on card B BEFORE typing the passphrase.
+        //    This exercises the pending-op queueing path (bug B).
+        //    The card should edit to "Queued behind an earlier card."
+        const kbB = await sc.driver.getKeyboard(sc.botUserId, cardB.messageId);
+        const approveB = kbB!
+          .flat()
+          .find((b) => b.callbackData !== undefined && /approve/i.test(b.text));
+        expect(approveB).toBeDefined();
+        await sc.driver.pressButton(sc.botUserId, cardB.messageId, approveB!.callbackData!);
+        await sc.expectMessage(/Queued behind an earlier card|Queued.*one passphrase/i, {
+          from: "bot",
+          timeout: 15_000,
+        });
+
+        // 5. Send passphrase. Gateway drains the queue, mints a
+        //    unioned grant for {KEY_A, KEY_B}, writes a single
+        //    .vault-token. BOTH cards edit to "Granted".
+        await sc.sendDM(passphrase);
+        await sc.expectMessage(new RegExp(`Granted[\\s\\S]*${KEY_A.replace("/", "\\/")}`), {
+          from: "bot",
+          timeout: 30_000,
+        });
+        await sc.expectMessage(new RegExp(`Granted[\\s\\S]*${KEY_B.replace("/", "\\/")}`), {
+          from: "bot",
+          timeout: 30_000,
+        });
+
+        // 6. Ask the agent to read BOTH keys. The load-bearing
+        //    assertion: pre-fix, the agent could only read ONE
+        //    (.vault-token had been overwritten with the second
+        //    grant's token, which only covered KEY_B). Post-fix,
+        //    the agent has a single token whose grant covers
+        //    BOTH keys, so BOTH gets succeed.
+        await sc.sendDM(
+          `Now run: switchroom vault get ${KEY_A} && switchroom vault get ${KEY_B} ` +
+          `— and paste the output verbatim. Include any error markers if either fails.`,
+        );
+        const finalReply = await sc.expectMessage(
+          new RegExp(SENTINEL_A),
+          { from: "bot", timeout: 90_000 },
+        );
+        expect(
+          finalReply.text,
+          `agent must read KEY_A — pre-fix this was the SECOND grant's key and would have succeeded; the union now covers it`,
+        ).toContain(SENTINEL_A);
+        expect(
+          finalReply.text,
+          `agent must read KEY_B — pre-fix this would have FAILED with VAULT-BROKER-DENIED because .vault-token was overwritten`,
+        ).toContain(SENTINEL_B);
+        expect(
+          finalReply.text,
+          `neither key should denied`,
+        ).not.toMatch(/VAULT-BROKER-DENIED/);
+      } finally {
+        await sc.tearDown();
+      }
+    },
+    420_000, // 7 min — covers two cards rendering + two approves +
+             //         passphrase round-trip + drain queue + two
+             //         mints + two vault gets.
+  );
+});