Read and verify an execution grant without consuming it

The grant resource. Decionis recomputes the SHA-256 hash of the canonical execution intent, evaluates policy, and issues a short-lived Ed25519 execution grant only for an ALLOW evaluated in ENFORCEMENT mode. This is the handler of the deprecated alias `POST /v1/authority/enforce-and-bind`, registered twice: every rule documented there (Idempotency-Key binding, Presence and attestation evidence, signed signals, MANAGED escalation, the verification envelope by client version, `context.decionis_policy`, the `decision:shadow` confinement, the scopes each mode needs and the workspace-owner rule, the EXPECTED_EFFECT_DIGEST_MISSING warning, and the BLOCK when a held allowance cannot be reserved) applies here unchanged. The issued grant is addressed afterwards as `/v1/authority/grants/{grantId}`, where `grantId` is the grant's `jti`: the `execution_token_jti` of this response, the `jti` recorded for the grant, and the `jti` claim of the signed execution token. `POST /v1/authority/evaluate` and `POST /v1/authority/enforce`, which the legacy `@decionis/sdk-node` 0.1.0 calls and this API never served, answer 410 `LEGACY_AUTHORITY_ROUTE_RETIRED` naming this route and `@decionis/sdk`, which replaces that package. `executor` (optional) says who will carry the grant out. It is never part of the canonical intent, its hash, or the grant's binding. When `executor.style` is `permit` and a grant was issued, the decision also carries `permit_id` (the grant's jti), `intent_sha256` (the intent hash as bare hex, written as `dossier_sha256` is) and `expires_at` (`execution_token_expires_at`). Without `executor`, or with `dispatch`, the response is exactly the enforce-and-bind response. A MANAGED escalation's locator-only summary carries no grant, so it never carries permit fields.