Bind tool approvals to an invocation generation

**Describe the bug**

Tool approvals are correlated only by provider-controlled tool-request IDs. If an approval prompt is cancelled and that ID is later reused, a delayed response for the old prompt can be delivered to the replacement invocation.

This affects both the generic tool-confirmation router and the separate ACP-provider confirmation map. The two implementations need one explicit compatibility and identity contract before either is changed independently.

---

**To Reproduce**

1. Start a tool invocation that requires approval.
2. Cancel or drop its approval waiter while the displayed callback can still complete.
3. Start a different tool invocation using the same provider request ID.
4. Deliver the delayed approval from step 1.
5. Observe that the approval can authorize the invocation from step 3.

---

**Expected behavior**

An approval must authorize only the exact invocation the user saw, even after cancellation, retries, stream replacement, or provider request-ID reuse.

The accepted design should choose and document one contract:

- Treat provider request IDs as session-unique and reject every reuse after cancellation, including a lifetime and memory-bounding policy.
- Preserve provider request-ID reuse by carrying a Goose-generated per-invocation generation through action-required display and confirmation callbacks.

Acceptance criteria should cover the generic confirmation router and the ACP-provider confirmation map, delayed Allow and Deny responses, dropped streams, concurrent distinct IDs, both agent loops, and bounded cleanup.

---

**Screenshots**

Not applicable.

---

**Please provide the following information**

- **OS & Arch:** All supported platforms
- **Interface:** CLI, Desktop, and ACP
- **Version:** `main` at `0a9749b1cbf38d182080a53286c4942629f66565`
- **Extensions enabled:** Any approval-gated tool
- **Provider & Model:** Any provider that reuses tool-request IDs

---

**Additional context**

Short-lived cleanup or a TTL does not bind a delayed response to the invocation the user saw. The solution must carry or enforce durable invocation identity across every display and callback path.

- [x] I have verified this does not duplicate an existing issue

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).

The issue describes a security flaw in tool-approval binding. Start by examining the generic tool-confirmation router and the separate ACP-provider confirmation map to understand the current ID correlation. Look for where tool-request IDs are generated and managed, and where approval callbacks are handled. The fix requires designing a contract for invocation identity, likely involving a per-invocation generation token. Check for existing tests around tool approvals to understand the expected behavior.

Vom Indexierungsmodell aus dem Issue-Text verfasst.