Task-level identity across multiple mandate chains: documented stance and linkage artifact?

[archerII]

Follow-up to #258 (cumulative state across mandate fulfilments) and #207 (cross-merchant budget enforcement), also related to the budget-field proposal in #133. Those threads establish that per-task cumulative caps are not carried by the protocol today and that enforcement location is topology-dependent. I'd like to ask the piece I don't think has been answered yet: task identity.

Concrete scenario (heterogeneous rather than repeated purchases): a user authorizes "buy me a phone, total cost under 350,000 HUF." The agent buys the phone for 348,500 (chain 1), then — because the box ships without a charger and the deadline matters — buys a charger for 4,990 at the same or another merchant (chain 2). Each Cart/Payment Mandate chain is individually well-formed and within any per-transaction constraint; jointly they exceed what the user meant by "total." Unlike the groceries example in #258, the two purchases are different line items serving one user-level task, potentially across different merchants.

Three questions:

1. Documented stance: is cumulative/task-level constraint evaluation intentionally out of scope for AP2 (as Cumulative state across mandate fulfilments -- where does it live? #258's operational discussion suggests), and is that boundary recorded anywhere in the spec or docs — or is it currently just implied by silence?

2. Task linkage: is there a defined identifier or artifact that lets a verifier associate multiple mandate chains with a single user-level task or Intent Mandate? Put differently: is the intended cardinality one Intent Mandate per task, per merchant, or per session? If one task legitimately spans several chains, is intent_mandate_id reuse across chains valid and meaningful to verifiers, or would each chain typically carry its own Intent Mandate?

3. If downstream by design: would an informative convention for task-level linkage (a join key, as sketched in the Cumulative state across mandate fulfilments -- where does it live? #258 comment thread) be in scope for the sample docs, so that orchestrators and verifiers converge on the same association rule instead of inventing incompatible ones?

Motivation: I'm evaluating what a task-level orchestration layer must provide on top of AP2 versus what it can expect from the protocol. "Total cost of the task" is how users state budgets, so understanding whether task identity is representable inside AP2 — or explicitly the orchestrator's job — shapes the design either way. Either answer is useful.