SendMessage and team mailbox internals switched to a detached 'ask' permission callback

What

• In the SendMessage tool's bridge/Remote Control send path, the permission-check helper used to be called directly with context and canUseTool. It's now invoked with an ask callback that calls the tool's canUseTool function with { detached: true }. This affects the isolatePeerMachines approval flow (the "isolatePeerMachines is enabled: sending to ... needs your approval" prompt) and the message-post call, which now takes { tool, sessionId, message, assistantMessage } instead of also passing context and canUseTool directly.
• The team-messaging tool's internal resolver for mailbox, live-agent, stopped-agent, and cloud-session cases now reads application state and message history through accessor functions (resolverState(), messages()) instead of a captured state snapshot. Resuming or asking permission for a stopped or cloud agent is now routed through a wrapping effect call using the same detached ask pattern, rather than passing canUseTool/toolUseContext directly.

Why

This is an internal plumbing change to how permission checks are requested for cross-machine and team messaging, replacing direct state/context passing with callbacks and accessors; it's not expected to change what approval prompts look like to a user.