Add supported TypeScript SDK authoring and delegation workflows for external consumers

[bordumb]

Finding

An external-repository stress test against the prepared @auths-dev/sdk@1.0.0-rc.1 tarball found that the TypeScript surface currently exposes only:

• loadAuths();
• Auths.verify(proofCbor, canonicalActionCbor, trustedContextCbor);
• the sealed VerifiedAction; and
• the three verification verdicts.

That is a useful low-level verifier, but it is not yet enough for an external application to attach an agent, author a grant, delegate narrower authority, construct the canonical profile action, or build the trusted verification context without reimplementing Auths protocol semantics.

The finding comes from the external consumer repository auths-agent-demo, which is intentionally forbidden from importing sibling source, copying Auths internals, or hand-rolling protocol CBOR.

Why this improves Auths

The primary SDK promise should let a normal application express authority workflows safely. If consumers must reproduce canonical encoding, scope attenuation, trusted-context construction, or profile-specific command decoding, the SDK transfers the most security-sensitive integration work to every adopter.

This is an ergonomics and security-boundary gap, not a request to replace the existing raw verifier. The low-level API can remain available as an advanced surface.

Proposed public workflow

Provide supported TypeScript SDK operations for:

• creating or importing a principal through provider-neutral signer/custody ports;
• planning and approving an exact grant;
• deriving a child grant whose scope cannot widen its parent;
• constructing canonical, profile-owned actions;
• assembling trusted verification context, evidence, status, and time inputs;
• verifying with the existing three-verdict model;
• decoding an authorized result into a profile-owned sealed command that alone can reach an effect gateway.

The workflow must remain usable without an Auths-hosted service and preserve browser, Node.js, headless, on-prem, macOS, Linux, and Windows use where the selected custody provider permits it.

Acceptance criteria

• An external repository can implement attach → grant → delegate → authorize without hand-authoring protocol CBOR.
• The happy path uses only a published immutable SDK package, not workspace or sibling imports.
• Child-grant helpers reject resource, verb, amount, expiry, or other scope widening before signing.
• Profile action constructors and authorized-command decoders remain profile-owned; no generic operation-tag executor is introduced.
• Denied and indeterminate results cannot be converted into an effect-capable command.
• Tests cover malformed input, stale status/evidence, replay, delegation widening, and command/profile mismatch.
• Documentation clearly separates convenient authoring helpers from authoritative verification.
• The low-level verifier remains available for advanced consumers.

Exclusions

This issue does not authorize package publication, a new RC tag, hosted infrastructure, custody-provider implementation, or expansion of an assurance claim. Those remain governed by their separate gates.