add protocol-neutral authorization seam

[Silentpartnercoding]

Closes #2.

What changed

• adds authorize(request) as a reusable fail-closed runtime API;
• verifies manifest integrity, Ed25519 signature, covered artifact integrity, and signed capability scope in one decision;
• adds withAuthorization(request, handler) so denied requests never invoke downstream handlers;
• adds nxtlinq-attest authorize <capability> with machine-readable JSON;
• uses exit 0 for allow, exit 2 for deny, and exit 1 for invalid usage;
• exports the authorization API from the existing package runtime;
• adds a deliberately small MCP gateway adapter example showing the protocol-neutral integration seam.

Why

The repository already exposes the individual trust inputs, but hosts need one callable decision before forwarding a protected operation. This PR creates that primitive without introducing protocol-specific policy, networking, identity logic, or receipt cryptography.

Protocol adapters can remain thin:

1. observe an operation;
2. map it to an existing signed capability;
3. call authorize;
4. forward only after allow;
5. translate the result into protocol-native behavior.

Behavioral guarantees

• valid signed in-scope capabilities return allow;
• out-of-scope capabilities return deny;
• missing, invalid, or altered signed context fails closed;
• downstream handlers run exactly once after allow and zero times after deny;
• evidence contains only manifest and artifact digests plus optional adapter metadata supplied by the caller.

Non-goals

• no ACP, MCP runtime, Buzz, or OAuth dependency;
• no networking;
• no second policy engine;
• no new cryptography;
• no claim of enforcement outside a host-controlled boundary;
• no signed decision-receipt primitive.

Validation

• npm install — passed
• npm run build — passed
• npm test — passed, 13/13 tests
• compatibility smoke test — init, scope, sign, and verify all exited 0

The authorization tests cover allow, scope denial, bare capability normalization, altered artifacts, downstream handler invocation counts, JSON CLI output, and allow/deny exit codes.

Maintainer decisions

1. Are tool:write and tool:exec the canonical capability names adapters should target?
2. Should optional session and resource metadata remain caller-provided evidence fields, or be digested before inclusion?
3. Should approval_required be introduced only when an approval service is available?