[Feat] Make Auto tool approvals presence-aware

[roomote-roomote]

​Opened on behalf of @daniel-lxs. View the task or mention @roomote-roomote for follow-up asks.

Related issue

Follow-up to #3084 (Automatic approvals), refining #3116 so Auto asks when the session owner can answer and blocks when the owner is away.

What changed

Auto mode now uses the session owner's presence to decide whether a non-routine call should pause or be blocked:

• Routine call, or an explicit Always allow choice -> the call runs as before.
• Risky or unavailable automatic check, owner present -> the existing native ask rule creates the normal pending approval row with autoEvaluation; the approval card explains that Auto flagged the call as risky or could not check it and asked the owner.
• Risky or unavailable automatic check, owner absent -> the existing native ask rule is answered with reject, the model receives an away-owner tool error with a path to allow the tool from the transcript, and a born-terminal auto_rejected audit row records the assessment.
• Web sessions use isSessionUserPresent({ sessionId, userId }) with a bounded lookup. A presence error or timeout is treated as present so an outage does not deny a call while someone is available to answer.
• Slack, Discord, Teams, and Telegram sessions are treated as present because the approval link is posted into the active conversation. Task approvals use the parent Session's owner and source surface, and the worker keeps mapping denied to the native reject.
• Native rule compilation and the text auto_rejected status remain unchanged; no migration or new rule shape is introduced.
• Settings and approval-card copy now says Auto asks before anything risky and explains that risky calls are blocked while the owner is away.

Why this change was made

#3116 correctly preserved the native Ask bridge and terminal Auto denial audit, but its unconditional fail-closed behavior also denied risky calls during a temporary check outage or while a session owner was present to answer. The follow-up review also found that Teams was omitted from the chat-surface exception, which would deny an active Teams owner without posting the approval link.

Impact

The same present-to-ask / absent-to-block policy applies to Fast session calls and task tool approvals. Teams now follows the same path as the other supported chat surfaces: no browser lease is required, and the existing session approval link is posted into the Teams conversation. Manual Always allow, Always ask, Reject, session overrides, expiry, and provider authorization ceilings remain authoritative.

Focused package suites pass: Fast approval coverage (65 tests), task approvals (20), worker relay (10), database approval audit (35), web card/settings (12), and the existing API suite (273 files, 3,170 tests). Root pnpm lint, pnpm check-types, pnpm check-types:fast, and pnpm knip pass; knip reports the existing apps/docs ignore configuration hint. The earlier failing Roomote code review check was tied to the Teams omission; the synchronized push retriggered it and it now passes with no code issues found.

No live judgment-model smoke run was possible in this sandbox because no reachable judgment backend or connected live integration was configured; the present, absent, unavailable, lookup-failure, and chat-surface paths are covered by focused tests.

Out of scope

• A notice to an owner who was away when Auto blocked a call; the session attention notifier is the natural follow-up location.
• The internal-MCP exemption tracked by [Fix] Approval control no longer gates Roomote-internal MCP servers #3101.

Checklist

• The PR title follows the repo convention.
• The change is scoped to presence-aware Auto approval behavior and the Teams review fix.
• Tests cover present, absent, unavailable, lookup-failure, and supported chat-surface paths.
• No secrets, tokens, private keys, or customer data are included in code or public review text.

[roomote-community]

No code issues found. See task

• Teams sessions are included in the present-to-ask flow and approval-link notification.

_{Reviewed e2599b0}