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

[chinawch007]

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 fix(runtime): land permission switches before the next turn's first tool call (#3349) #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.

[chinawch007]

take

[chinawch007]

I will start when #3615 merged.