Define mode-change semantics for in-flight tool requests

What problem would this solve?

Goose mode can change while a tool request is being inspected, awaiting approval, running a pre-tool hook, or waiting in a multi-request batch. Today the legacy and state-machine agent loops can observe those changes at different points. Local mode checks cannot close every window, and a Chat-to-Auto change can let a pending state-machine request reach execution without fresh inspection.

What would a good outcome look like?

Both agent loops use one explicit rule for every pending tool request:

• which mode governs the request: creation, inspection/approval, or dispatch;
• whether switching to Chat skips, cancels, or allows already-approved and already-started work;
• whether switching back to an execution mode requires fresh inspection and approval; and
• how the rule applies to ordinary tools, skills, structured final output, unknown tools, hooks, and batches.

The chosen rule should be represented as durable per-request state so an asynchronous boundary cannot silently change the authorization decision.

Possible approaches

• Record the mode or a mode-generation value when each request is inspected, and require it to match again at dispatch.
• Give each request an explicit inspection/authorization state instead of treating missing executable metadata as executable.
• Define mode transitions to cancel or skip all pending requests, with a new model turn required before tools can run again.

The main trade-offs are predictable safety behavior, whether already-approved work is interrupted, avoiding repeated approval prompts, and keeping the two agent loops compatible during migration.

Decision needed

When mode changes while tool requests are pending, which mode governs each request—request creation, inspection/approval, or dispatch—and should switching to Chat cancel or skip already-approved or in-flight work while switching back requires fresh inspection?

Additional context

This needs an agreed transition policy before another implementation is attempted. A sequence of checks around individual await points only moves the race to the next asynchronous boundary.

• I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches Ready on the Goose Issues board.