Bug: Stale permission.resolve commands are acknowledged as completed

## Type

Bug

## Problem

The driver acknowledges `permission.resolve` commands as completed even when the requested permission resolver no longer exists. The API can then remove the request from viewer state even though the driver did not apply the user's decision.

This does not grant permission, but it creates incorrect state and confusing UI behavior around timed-out, cancelled, or already-resolved permission requests.

## Evidence

- `apps/driver/src/core/driver-permission-broker.ts:47-52` returns a boolean from `resolve`.
- `apps/driver/src/core/driver-permission-broker.ts:63-73` returns `false` when the resolver is missing.
- `apps/driver/src/core/driver-command-dispatcher.ts:217-224` ignores that boolean and sends a completed command update.
- `apps/api/src/modules/runtime/application/session-runs/resolve-permission-request.service.ts:22-64` sends the command after checking the active driver/run link.
- `apps/api/src/modules/runtime/application/session-runs/session-permission-decision.service.ts:94-128` removes the permission request from local state after sending the command.

## Expected behavior

Resolving an unknown or stale permission request should be explicit failure, not a completed command.

## Suggested fix

Make the driver send a failed command update when `permissionRequests.resolve()` returns `false`, with a code such as `permission_request_not_found`.

Then ensure the API only removes pending permission state when the driver acknowledgement or `permission.resolved` event confirms the decision was applied.

## Verification

- Add a driver test where an unknown `permission.resolve` command results in command failure.
- Add an API/session test proving stale resolution does not silently clear pending permission state, or returns a clear error.

## Source

Local audit: `.local/api-driver-bug-design-audit-2026-06-26.md`