- Updated test #1 to reflect Ctrl+h testing
- Added test #1b for fallback keys (F1, Ctrl+?)
- Updated dialog content display to highlight Ctrl+h
- Updated status bar integration test

Assisted-By: docker-agent

Running '--sandbox' twice for the same workspace with different
mounts (e.g. with vs without --no-kit, or after the kit feature was
added on top of an existing setup) was leaving the user with
suffixed sandbox names and confusing 'Note: sandbox already exists,
creating ...-2 instead' warnings, ultimately ending in:

  Error: opening filesystem /Users/dgageot/.agents:
    open /Users/dgageot/.agents: no such file or directory

Two compounding bugs:

1. 'sbx rm <name>' prompts for confirmation when stdin isn't a TTY
   ('ERROR: stdin is not a terminal; use --force to skip
   confirmation'). Our previous _ = rmCmd.Run() / CombinedOutput()
   call was running it without --force and without stdin attached,
   so every rm silently failed and the stale sandbox lived on. Then
   docker / sbx create detected the name as taken and suffixed the
   new sandbox with -1, -2, ... which never went away.

2. ForWorkspace returned only the FIRST match, but the same primary
   workspace can end up bound to several sandboxes once suffixing
   has happened. We were checking the canonical name's mounts (no
   kit, no .agents), finding it stale, trying to rm it (silent
   failure per #1), and creating yet another suffix on top of the
   pile.

Fix:

* Add an rmExtraArgs field on the Backend struct. The sbx backend
  fills it with ["--force"]; the docker backend leaves it nil
  because its rm has no confirmation prompt and rejects --force.
  Backend.rm wraps the per-backend invocation so callers don't have
  to remember.

* New Backend.allForWorkspace returns every sandbox whose primary
  workspace matches wd. Ensure walks the whole list, reuses the
  first one whose mounts already cover the requested set, and
  otherwise removes every match before creating a fresh sandbox.
  ForWorkspace stays as the 'first match' convenience.

* The cleanup loop logs each rm at WARN when it fails so the next
  diagnosis isn't silent. After a successful run there is exactly
  one sandbox per workspace with the canonical name.

Verified by reproducing the user's broken state (two stale
sandboxes for the same workspace, one with the wrong mounts, one
with no useful mounts), then running 'docker agent run --sandbox
gopher': both stale sandboxes are removed and a single canonical
'docker-agent-<workspace-hash>' is created in their place.

Running '--sandbox' twice for the same workspace with different
mounts (e.g. with vs without --no-kit, or after the kit feature was
added on top of an existing setup) was leaving the user with
suffixed sandbox names and confusing 'Note: sandbox already exists,
creating ...-2 instead' warnings, ultimately ending in:

  Error: opening filesystem /Users/dgageot/.agents:
    open /Users/dgageot/.agents: no such file or directory

Two compounding bugs:

1. 'sbx rm <name>' prompts for confirmation when stdin isn't a TTY
   ('ERROR: stdin is not a terminal; use --force to skip
   confirmation'). Our previous _ = rmCmd.Run() / CombinedOutput()
   call was running it without --force and without stdin attached,
   so every rm silently failed and the stale sandbox lived on. Then
   docker / sbx create detected the name as taken and suffixed the
   new sandbox with -1, -2, ... which never went away.

2. ForWorkspace returned only the FIRST match, but the same primary
   workspace can end up bound to several sandboxes once suffixing
   has happened. We were checking the canonical name's mounts (no
   kit, no .agents), finding it stale, trying to rm it (silent
   failure per #1), and creating yet another suffix on top of the
   pile.

Fix:

* Add an rmExtraArgs field on the Backend struct. The sbx backend
  fills it with ["--force"]; the docker backend leaves it nil
  because its rm has no confirmation prompt and rejects --force.
  Backend.rm wraps the per-backend invocation so callers don't have
  to remember.

* New Backend.allForWorkspace returns every sandbox whose primary
  workspace matches wd. Ensure walks the whole list, reuses the
  first one whose mounts already cover the requested set, and
  otherwise removes every match before creating a fresh sandbox.
  ForWorkspace stays as the 'first match' convenience.

* The cleanup loop logs each rm at WARN when it fails so the next
  diagnosis isn't silent. After a successful run there is exactly
  one sandbox per workspace with the canonical name.

Verified by reproducing the user's broken state (two stale
sandboxes for the same workspace, one with the wrong mounts, one
with no useful mounts), then running 'docker agent run --sandbox
gopher': both stale sandboxes are removed and a single canonical
'docker-agent-<workspace-hash>' is created in their place.

Running '--sandbox' twice for the same workspace with different
mounts (e.g. with vs without --no-kit, or after the kit feature was
added on top of an existing setup) was leaving the user with
suffixed sandbox names and confusing 'Note: sandbox already exists,
creating ...-2 instead' warnings, ultimately ending in:

  Error: opening filesystem /Users/dgageot/.agents:
    open /Users/dgageot/.agents: no such file or directory

Two compounding bugs:

1. 'sbx rm <name>' prompts for confirmation when stdin isn't a TTY
   ('ERROR: stdin is not a terminal; use --force to skip
   confirmation'). Our previous _ = rmCmd.Run() / CombinedOutput()
   call was running it without --force and without stdin attached,
   so every rm silently failed and the stale sandbox lived on. Then
   docker / sbx create detected the name as taken and suffixed the
   new sandbox with -1, -2, ... which never went away.

2. ForWorkspace returned only the FIRST match, but the same primary
   workspace can end up bound to several sandboxes once suffixing
   has happened. We were checking the canonical name's mounts (no
   kit, no .agents), finding it stale, trying to rm it (silent
   failure per #1), and creating yet another suffix on top of the
   pile.

Fix:

* Add an rmExtraArgs field on the Backend struct. The sbx backend
  fills it with ["--force"]; the docker backend leaves it nil
  because its rm has no confirmation prompt and rejects --force.
  Backend.rm wraps the per-backend invocation so callers don't have
  to remember.

* New Backend.allForWorkspace returns every sandbox whose primary
  workspace matches wd. Ensure walks the whole list, reuses the
  first one whose mounts already cover the requested set, and
  otherwise removes every match before creating a fresh sandbox.
  ForWorkspace stays as the 'first match' convenience.

* The cleanup loop logs each rm at WARN when it fails so the next
  diagnosis isn't silent. After a successful run there is exactly
  one sandbox per workspace with the canonical name.

Verified by reproducing the user's broken state (two stale
sandboxes for the same workspace, one with the wrong mounts, one
with no useful mounts), then running 'docker agent run --sandbox
gopher': both stale sandboxes are removed and a single canonical
'docker-agent-<workspace-hash>' is created in their place.

Running '--sandbox' twice for the same workspace with different
mounts (e.g. with vs without --no-kit, or after the kit feature was
added on top of an existing setup) was leaving the user with
suffixed sandbox names and confusing 'Note: sandbox already exists,
creating ...-2 instead' warnings, ultimately ending in:

  Error: opening filesystem /Users/dgageot/.agents:
    open /Users/dgageot/.agents: no such file or directory

Two compounding bugs:

1. 'sbx rm <name>' prompts for confirmation when stdin isn't a TTY
   ('ERROR: stdin is not a terminal; use --force to skip
   confirmation'). Our previous _ = rmCmd.Run() / CombinedOutput()
   call was running it without --force and without stdin attached,
   so every rm silently failed and the stale sandbox lived on. Then
   docker / sbx create detected the name as taken and suffixed the
   new sandbox with -1, -2, ... which never went away.

2. ForWorkspace returned only the FIRST match, but the same primary
   workspace can end up bound to several sandboxes once suffixing
   has happened. We were checking the canonical name's mounts (no
   kit, no .agents), finding it stale, trying to rm it (silent
   failure per #1), and creating yet another suffix on top of the
   pile.

Fix:

* Add an rmExtraArgs field on the Backend struct. The sbx backend
  fills it with ["--force"]; the docker backend leaves it nil
  because its rm has no confirmation prompt and rejects --force.
  Backend.rm wraps the per-backend invocation so callers don't have
  to remember.

* New Backend.allForWorkspace returns every sandbox whose primary
  workspace matches wd. Ensure walks the whole list, reuses the
  first one whose mounts already cover the requested set, and
  otherwise removes every match before creating a fresh sandbox.
  ForWorkspace stays as the 'first match' convenience.

* The cleanup loop logs each rm at WARN when it fails so the next
  diagnosis isn't silent. After a successful run there is exactly
  one sandbox per workspace with the canonical name.

Verified by reproducing the user's broken state (two stale
sandboxes for the same workspace, one with the wrong mounts, one
with no useful mounts), then running 'docker agent run --sandbox
gopher': both stale sandboxes are removed and a single canonical
'docker-agent-<workspace-hash>' is created in their place.

The RFC 8414 §3.1 path-aware variant added in e3fed03 is a speculative
guess about where an authorization server *might* publish its metadata.
Several real-world deployments answer that URL with something other
than 404 (e.g. a gateway that returns 403 for unknown well-known
prefixes, or a 5xx from an upstream component) while still serving
valid metadata at the legacy 'append-to-issuer' URL.

Before this change, getAuthorizationServerMetadata short-circuited on
the first non-404 status with a hard error, even though further
candidates would have succeeded. That regressed every issuer with a
path component whose path-aware endpoint doesn't 404.

Probe semantics now:

  - 200 with a decodable body wins immediately.
  - Non-404 statuses, transport errors and JSON-decode failures are
    logged and the next candidate is tried.
  - If at least one candidate produced a non-404 status or a
    transport-level error and none returned 200, surface the most
    diagnostic failure so a misconfigured auth server is still visible.
  - If every candidate 404'd, fall back to default metadata exactly as
    before (legacy behaviour).

Covered by three new tests:

  - TestGetAuthorizationServerMetadata_NonFatalCandidateStatus: 403 on
    candidate #1, 200 on candidate docker#2 → success.
  - TestGetAuthorizationServerMetadata_AllUnreachableSurfacesError: every
    candidate 500s → error surfaced.
  - TestGetAuthorizationServerMetadata_All404FallsBackToDefaults:
    legacy behaviour preserved.