refactor(storage): Remove the obsolete SessionManager.setPermissionMode compatibility path

## Problem

`SessionManager.setPermissionMode` is a historical API that no longer has any production callers.

The method was introduced before Runtime Host became the authority for Session configuration. After the configuration architecture was consolidated in #1651, the production callers moved to the versioned `session.configuration.update` operation:

- Desktop's `sessions:setPermissionMode` IPC handler calls `updateConfiguration`.
- The CLI session driver also updates `permissionMode` through the configuration operation.
- Both paths ultimately reach `SessionManager.transitionSessionConfiguration`.

No production path calls `SessionManager.setPermissionMode` directly today. Its remaining direct callers are Runtime unit tests.

This was discovered while developing #3615. That PR initially placed part of its permission-transition behavior behind `SessionManager.setPermissionMode`, which exposed that the method was no longer on the real Desktop or CLI caller path. #3615 subsequently moved the behavior to the production configuration authority.

For compatibility and to keep #3615 focused, the method is temporarily retained there as:

1. a thin wrapper around `transitionSessionConfiguration` for stores that expose the versioned configuration methods; and
2. a legacy fallback for `SessionStore` implementations that do not expose those currently optional methods.

This leaves redundant code and two apparent entry points for the same operation. Although the fallback reuses the canonical boundary-transition policy, retaining it increases the risk that audit behavior, Deep Research cleanup, revision handling, or permission-transition semantics diverge again.

This issue tracks removing that historical compatibility path after #3615 lands.

### Scope clarification

This issue concerns the internal `SessionManager.setPermissionMode` method.

Desktop and CLI also have UI or driver methods named `setPermissionMode`. Those methods are still used and may retain their public names; they already route changes through `session.configuration.update` and are not the obsolete API described here.

## Desired outcome

Make the versioned Session configuration operation the only Runtime authority for changing a persisted permission mode.

The follow-up should:

- Remove `SessionManager.setPermissionMode`.
- Remove `setPermissionModeWithLegacyStore` and the temporary legacy-store fallback introduced in #3615.
- Remove helpers that become unused after deleting the compatibility path.
- Delete wrapper-specific tests that only exercise the obsolete method.
- Move any behavior-level coverage that is still valuable to `transitionSessionConfiguration` or, preferably, to the Host `session.configuration.update` operation.
- Preserve coverage for:
- permission widening and narrowing;
- active ordinary Turns and Goal continuations;
- configuration revision conflicts;
- Deep Research label cleanup;
- `mode_change` audit notes;
- pending Interaction rejection.
- Review whether the versioned Session configuration capabilities should become required in the `SessionStore` contract, or otherwise document that stores wishing to mutate Session configuration must provide them.

## Acceptance criteria

- There are no direct calls to `SessionManager.setPermissionMode` because the method no longer exists.
- Persisted permission-mode changes have one authority: `session.configuration.update` / `transitionSessionConfiguration`.
- No separate legacy transition policy remains in `SessionManager`.
- Production Desktop and CLI permission switching continues to work through the configuration operation.
- Relevant behavioral tests exercise the authoritative production path instead of a compatibility wrapper.
- Permission-transition audit and cleanup behavior remains unchanged.

## Alternatives or workarounds

The alternative is to keep `setPermissionMode` indefinitely as a compatibility wrapper.

That does not provide value to current production callers, and it preserves an API that appears authoritative despite being bypassed by the actual Desktop and CLI paths. The temporary wrapper in #3615 is useful for keeping that PR scoped and compatible, but it should not become a permanent second entry point.