bug: full-access CAS threads can still prompt or stay stuck pending

[kesslerio]

What happens

A CAS thread can get stuck in the middle of a permission upgrade after stale interactive state is left behind.

In practice this shows up as /cas_status continuing to print:

• Permissions: Default
• Permissions note: Full Access will apply after the current Codex turn ends.

That can keep happening even after /cas_cancel or after the original interactive action is already dead.

There is a second user-facing symptom on the same path: a thread that is already supposed to be Full Access can still surface requestApproval prompts for dangerous commands instead of bypassing the approval bridge entirely.

Repro

1. Bind a CAS thread and switch it to Full Access.
2. Trigger a command that produces a Codex interactive approval or questionnaire.
3. Let the interactive state go stale, or cancel the run while that state is still hanging around.
4. Check /cas_status or try another dangerous command.

Expected

• Full Access threads should not prompt for requestApproval.
• If the run is gone, stale interactive state should be cleaned up.
• Pending permission migration should either apply or clear itself instead of staying stuck forever.

Actual

• The thread can stay in Default with a permanent Full Access will apply after the current Codex turn ends note.
• Stale pending callbacks can outlive the run that owned them.
• Dangerous commands can still hit the approval bridge even though the thread is supposed to be Full Access.

Notes

This looks like two parts of the same lifecycle bug:

• the client path still forwards some requestApproval events instead of auto-accepting them for Full Access threads
• controller cleanup paths clear some stale state, but not enough to unblock pendingPermissionsMode migration when the owning run is already gone or no longer accepting input

Related background:

• Plugin: match Codex Desktop permission modes #11 introduced explicit permission profiles
• bug: cas_plan questionnaire callbacks lose active run after the first question #93 tracks another stale questionnaire/run lifecycle bug
• Plugin: clear stale pending approval buttons #79 is adjacent, but focuses on clearing stale approval UI rather than unblocking permission migration

[kesslerio]

Confirmed a second failure mode beyond the stale pending-input cleanup this PR already addresses.

What I reproduced in live debugging:

• /cas_status reported Permissions: Full Access
• the next dangerous command still emitted a Codex approval prompt
• replying to that prompt then hit pending-input callback missing active run

Root cause chain:

• the stored binding for the thread was actually back to permissionsMode: "default"
• new turns choose their profile from the stored binding, so they still started in the default profile and could emit requestApproval
• meanwhile the status view was showing permissions derived from live thread state, not from the persisted binding state that future turns would use
• earlier in the same topic, the plugin had already logged bound restore could not read thread state followed by clearing stale binding, which removed the old binding record and its remembered permission mode

So this looks like a second lifecycle bug:

1. stale binding recovery can discard the conversation's intended permission mode
2. a later rebind falls back to default
3. /cas_status can still present Full Access from thread state, which hides the mismatch
4. the next turn runs as default and approvals come back

Relevant code paths:

• src/controller.ts: startTurn() uses getPermissionsMode(binding) to choose the run profile
• src/controller.ts: clearStaleBinding() fully unbinds the conversation
• src/controller.ts: bindConversation() defaults to default when no explicit permissionsMode is carried over
• src/controller.ts: buildStatusText() renders permissions from thread state/effective state, which can drift from the persisted binding profile

This means the fix for #105 likely needs one more pass after the current PR:

• preserve or recover intended permission mode across stale-binding cleanup / rebind
• make status/reporting reflect persisted binding mode vs live thread mode clearly enough that this mismatch is visible
• add regression coverage for stale restore -> rebind -> next turn still starts with the expected permissions profile