Proposal: IntentRail extension for authorization-bound task execution

### Is your feature request related to a problem? Please describe.

A2A defines how agents exchange messages, create tasks, move them through states,
and return results. For actions with external side effects, it does not currently
define a portable way to:

- state the exact action and its limits before execution;
- bind an approval or authorization to that exact request;
- prevent a retry or replay from becoming a second execution; and
- connect the final result to the intent and authorization that allowed it.

Individual applications can put these fields in metadata, but without shared
lifecycle rules two implementations can interpret the same exchange differently.

### Describe the solution you'd like

I would like to explore an A2A extension called **IntentRail**. The extension
would add a small set of linked records around an A2A task:

1. a preflight record containing the normalized action intent, bounds, and
relevant context;
2. an authorization reference bound to that record;
3. a stable execution identity used for retries and replay handling; and
4. an outcome record linked back to the request and authorization.

The records would be connected with canonical digests, with deterministic
rejection behavior when a binding is missing or changed. Support would be
declared through an `AgentExtension` URI, so this could be tested without
changing the A2A core specification.

IntentRail would not define a policy language, token format, payment protocol,
or a universal receipt format. Those can remain separate systems referenced by
the extension.

A short proposal, worked example, and open questions are here:
https://selvamanoharan.github.io/intentrail-proposal/

If the scope is useful to the project, I would appreciate maintainer feedback
and a sponsor for an `experimental-ext-intentrail` experiment.

### Describe alternatives you've considered

- **Application-specific metadata:** workable within one deployment, but it
does not give independently implemented agents common validation or replay
semantics.
- **Only reference external permit/evidence artifacts:** compatible with this
proposal, but references alone do not define the A2A-side lifecycle
invariants that bind a task to one authorized execution.
- **Add the behavior directly to A2A core:** this seems premature. An
experimental extension would allow the shape and conformance cases to be
tested first.

### Additional context

These are the discussions I found most relevant:

- #1769 covers verifier-side admission and adjacent permit/evidence/receipt
artifacts. It appears to be the closest architectural discussion. IntentRail
focuses on the A2A-side lifecycle rules and can reference those artifacts.
- #1716 discusses capability-token enforcement at the skill boundary.
- #1956 discusses structured business intent and fulfillment constraints.
- #1976 discusses requester acceptance or rejection of task output.
- #1847 discusses post-execution receipts linked to upstream authority.

From what I could find, none of these proposes the same end-to-end A2A
lifecycle binding. I may have missed another discussion, or misunderstood the
intended scope of one of the issues above, so pointers and corrections would be
very welcome. My current reading is that these ideas are complementary rather
than replacements.

A prototype and conformance work exist, but the implementation repository is
remaining private while security hardening and history cleanup are completed.
The public proposal is intentionally self-contained so the architecture can be
reviewed without access to that code.

Questions I would especially value feedback on:

1. Is this appropriately scoped as an A2A extension?
2. Should the extension standardize full records, references, or both?
3. Which fields need canonicalization for cross-implementation verification?
4. Which replay and partial-failure cases should be required conformance tests?
5. Would a maintainer be willing to sponsor an experimental repository if the
direction is acceptable?

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct