Manifest-bound delegatable auth

Description

The pitch.

# Charan Auth Delegation Submission

## Summary

This submission targets Problem 04, **Delegatable capability tokens with
cascading revocation**, in the Auth layer.

It adds `auth: manifest_delegatable`, a small Auth-layer plugin that issues and
verifies capability tokens constrained by signed policy manifests. A root
token can only contain scopes allowed by the subject's manifest, and a
delegated child token can only carry a strict subset of its parent token's
scopes. Verification fails closed for invalid signatures, malformed payloads,
scope widening, stale ancestors, expired tokens, and audience confusion.

Current-main note: NANDA Town now also includes `auth: delegatable` from
merged PR #138 and `auth: mesh_revocable` from merged PR #155. This PR
intentionally uses its own `manifest_delegatable` namespace and focuses on
what those merged plugins do not cover: identity-verified manifests,
manifest-bound root issuance, budget/approval policy decisions, `spend:` and
`expose:` scope grammar, and strict rejection of equal-authority delegation.

## Problem Solved

Multi-agent workflows routinely pass capabilities down a chain:

1. A coordinator receives a broad but bounded root capability.
2. The coordinator delegates narrower capabilities to intermediary agents.
3. Intermediaries delegate still narrower capabilities to leaf agents.
4. A verifier must reject any child token that tries to exceed the declared
   parent, manifest, expiry, or audience boundary.

The default `jwt` Auth plugin can sign and revoke exact tokens, but it cannot
model parent-issued delegation. A central authority can re-issue a new token,
but that is not the same security property: it does not prove that the parent
holder was constrained to a subset, and it does not create a delegation chain
that can be audited or revoked transitively.

This PR makes the missing Auth-layer behavior explicit:

- **Manifest-bound roots.** Root issuance clamps requested scopes against a
  signed `PolicyManifest`.
- **Manifest tamper defense.** A manifest widened after signing verifies
  false and produces an empty-authority root token in the adversarial scenario.
- **Least privilege delegation.** Child scopes must be a strict subset of
  parent scopes.
- **Fail-closed verification.** Invalid manifests, tampered token payloads,
  malformed payloads, unknown tokens, invalid signatures, expired tokens, and
  invalid chains are rejected.
- **Cascading revocation.** Revoking any token invalidates that token and all
  descendants because descendants carry ancestor token ids.
- **Audience binding.** A child token minted for `leaf-0-0` does not verify
  when presented by `leaf-0-0-wrong`.
- **Auditability.** The deterministic `manifest_delegated_auth` scenario emits trace
  lines for honest leaf verification and each adversarial probe, and the
  validators check those trace lines.

## Why It Matters

Agents often need to receive or delegate authority without inheriting every
permission their parent has. Without manifest-bound delegation, a child agent
can be over-privileged by accident, and a test rig cannot distinguish a real
least-privilege protocol from central re-issuance that happens to work on the
happy path.

The security properties this PR makes testable are:

- **Least privilege:** only declared scopes survive issuance and delegation.
- **Manifest-bound authority:** an agent cannot ask for scopes beyond its
  signed manifest, and a tampered or forged manifest fails closed when an
  identity verifier is supplied.
- **Scope narrowing:** delegation must strictly reduce authority, not merely
  copy parent authority.
- **Revocation propagation:** a stale child cannot survive ancestor revocation.
- **Audience separation:** a valid token is not enough; the presenter must be
  the intended audience when the caller supplies a presenter.
- **Deterministic audit:** the scenario and validators produce stable evidence
  for the judge panel and CI.

## What Works Today

### Auth Plugin



…