[ENHANCEMENT] Tighten Task.ask sequencing for auto-approved read-only asks #105

Problem (one or two sentences)

Task.ask inserts a visible ask row before synchronous read-only auto-approval resolves it. That sequencing allows auto-approved read_file asks to briefly appear as actionable approval state.

Context (who is affected and when)

This affects users with read-only auto-approve enabled, especially during fast repo exploration. It is the root-cause backend slice for issue #102.

Desired behavior (conceptual, not technical)

If a read-only tool ask will be auto-approved immediately, the task flow should not surface it as a visible actionable approval state first.

Constraints / preferences (optional)

Keep this change narrow to synchronous auto-approved read-only tool asks. Do not turn it into a broad refactor of all approval flows.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

• https://app.roomote.dev/task/2t7u9db2gc882

Acceptance criteria (optional)

• Auto-approved read_file asks do not surface as visible actionable approval state.
• Manual approval flows still behave as expected.
• A focused task-level regression test covers the synchronous auto-approve path.
• The change remains reviewable as a 1 SP backend slice under [ENHANCEMENT] Reduce approval-control flash for auto-approved read-only asks #102.

Proposed approach (optional)

Tighten the sequencing in Task.ask for the synchronous read-only auto-approve path so the ask is not exposed to the UI as an unresolved actionable approval state before auto-approval lands.

Trade-offs / risks (optional)

This touches shared approval sequencing, so the main risk is unintended behavior changes for other ask types. Keep the scope tight and verify only the targeted path plus nearby approval behavior.