Map delegation-framework caveats to exo interface guards

[sirtimid]

Issue #871 concluded that "the majority of gator delegations can be represented by M.* from @endo/exo" and was closed without the mapping being built. packages/evm-wallet-experiment/src/lib/caveats.ts implements only the on-chain encoding side (encodeAllowedTargets, encodeAllowedMethods, encodeAllowedCalldata, encodeValueLte, encodeLimitedCalls, encodeTimestamp, and so on).

So we have asserted a correspondence between on-chain attenuated delegation and in-kernel attenuated capabilities, and never demonstrated it. Worth doing properly, because it is the concrete artifact of the claim that the two models compose rather than compete.

Sketch of the mapping to validate or refute:

Caveat	Candidate kernel equivalent
allowedMethods	the interface guard's method set
allowedCalldata, valueLte	argument patterns (M.lte, M.eq, ...)
limitedCalls	a wrapper holding a use counter
timestamp	an expiring wrapper
allowedTargets	no equivalent needed — holding the reference is the target restriction

That last row is the interesting one, and the reason this is worth writing down rather than just discussing: an entire caveat category exists only because the on-chain model has no notion of an unforgeable reference.

Deliverables:

• The full table, including caveats with no clean kernel equivalent and guards with no caveat equivalent.
• A note on revocation semantics, which differ materially: on-chain revocation requires a transaction (cost, latency, public), kernel revocation is immediate and local. If a grant spans both layers, which is authoritative, and what happens in the window between them?
• A recommendation on whether a caveat set can be mechanically compiled to a guard, or whether the correspondence is only conceptual.

Related: #871 (closed), #539.