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).

L’issue décrit une faille de sécurité dans la liaison des approbations d’outils. Commencez par examiner le routeur générique de confirmation des outils et la map de confirmation distincte d’ACP-provider afin de comprendre la corrélation actuelle des ID. Recherchez où les ID des requêtes d’outils sont générés et gérés, et où les callbacks d’approbation sont traités. Le correctif nécessite de concevoir un contrat pour l’identité de l’invocation, probablement avec un jeton de génération propre à chaque invocation. Vérifiez les tests existants concernant les approbations d’outils afin de comprendre le comportement attendu.

Rédigé par le modèle d'indexation à partir du texte de l'issue.