Define trust-state behavior for resumed recipe sessions and MCP App actions

**What problem would this solve?**

Recipe trust is resolved asynchronously against the exact recipe identity. The fresh-start path can gate the initial prompt, but resumed or already-pending sessions may expose controls before that lookup finishes. Goose does not currently have an accepted behavior contract for queued steering, message edits and forks, pending tool approvals, elicitation, recipe activities, MCP App submissions, or MCP App host actions while trust is pending or rejected.

Without that contract, a narrow submission fix expands across many components and creates unclear UX and compatibility behavior. Scheduled and non-recipe sessions also need explicit treatment.

**What would a good outcome look like?**

An accepted state/action matrix should define behavior for fresh and resumed recipe sessions in pending, accepted, rejected, and changed-recipe states. It should say which actions remain available, which fail closed, what user feedback appears, and when an existing session may rely on prior acceptance.

**Possible approaches**

- Resolve acceptance for the exact recipe before creating its session: rejection creates no session, while an accepted recipe creates a session that thereafter follows the normal session security model, including import and resume behavior.
- Gate only manual submissions and recipe activities, treating post-start controls as authorized by the existing session.
- Fail closed for every action that can advance or mutate an agent run until the exact current recipe is accepted.
- Pause resumed recipe sessions as a whole during trust resolution, with an explicit pending/rejected UI.
- Split behavior by action type, documenting why tool approval, elicitation, edits/forks, steering, and MCP App actions have different trust semantics.

The decision should specify whether acceptance belongs before session creation or remains session-local, preserve scheduled and non-recipe behavior, and account for imported and resumed-session compatibility. PR #11457 demonstrates the affected surface and was closed so this behavior can be agreed before implementation resumes.

**Additional context**

- [x] 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](https://github.com/orgs/aaif-goose/projects/1).