[TheGreatAxios]

Summary

Myra (the assistant workflow) can create new specialist agents, but had
no way to give them scoped access -- reconcileSeedGrants was the only
grant writer. This adds @corbits/access-tools, a tool package with:

• list_principals -- list principals (users, agents, workflow runs) in
  the calling agent's tenant.
• list_grants -- list grants, optionally filtered by principalId or
  resource.
• grant_access (approval: "ask") -- grant a principal one or more
  actions on a resource; a human approves each grant before it lands.
• revoke_access (approval: "ask") -- revoke a grant by id.

The package's own routes.ts adds a workflow-run-authenticated mirror
of the tenant's principal/grant surface at /api/workflow-access,
authorized through Interchange's real grant store and condition
registry (createRequireGrant/@intx/authz) -- the same check every
session-authenticated route runs, not a bundle-local approximation.

Delegation ceiling (review fix)

POST /grants and DELETE /grants/:grantId previously only checked
that the caller held grant:*/create (or manage), never that the
requested (resource, action) pairs were within what the caller's own
principal already holds -- a self-escalation hole. Both routes now call
@intx/authz's authorize() per requested pair, against the SAME
grant store createRequireGrant's middleware checks, and refuse with a
403 naming the first disallowed pair. Revoke applies the identical
ceiling to the grant's own (resource, action) before deleting it.

Myra-only grant scoping (review fix)

The four access-tools grants (principal:* read, grant:*
read/create/manage) previously lived in SEED_GRANTS, which
reconcileSeedGrants plants on every tenant's shared principal --
letting that principal read and mint grants for every principal in the
tenant, not just the specialist agents Myra stands up herself. They are
now planted only on the assistant workflow's own run principal, via
plantAssistantAccessToolsGrants in packages/seeding/src/seed.ts.
That principal id is derived with deriveRunPrincipalId(tenantId, deploymentId) -- the same deterministic derivation
@intx/hub-api's workflow-run-trigger uses to mint a run principal
on a deployment's first materialized trigger. It stays stable across a
relaunch because it's keyed to the deployment's own top-level run id,
not to a fresh per-invocation run id. The grants are planted only after
confirmDeploymentAnswers has actually triggered the assistant
deployment (confirmDeployments: true), since that trigger is what
commits the run-principal row these grants reference; the connect
flow's confirmDeployments: false path defers this to the tenant's
next workbench seed run.

Wired in:

• apps/hub/src/index.ts -- mounts the routes, reusing the same
  chatGrantStore/chatConditionRegistry every other extension checks
  against.
• apps/sidecar/src/workflow-substrate-factory/step-env.ts -- threads
  hubAccessUrl onto the step env, same hub origin as every other
  manager-tools bundle.
• packages/tool-registry-publish/src/registry.ts -- publishes the
  package into the corbits-tools registry.
• packages/seeding/src/seed.ts -- plants the four access-tools grants
  on Myra's own run principal instead of SEED_GRANTS.

No vendor edits -- @intx/authz, @intx/db, and @intx/hub-api's own
createRequireGrant/idResource/authorize exports are consumed as
published dependencies.

Test plan

• bunx tsc --noEmit -p packages/access-tools
• bunx tsc --noEmit -p apps/hub
• bunx tsc --noEmit -p packages/seeding
• bun test packages/access-tools (91 pass, incl. new
  routes.test.ts DB-gated ceiling suite: 401/403/403/201/403/404)
• bun test packages/seeding
• bun run check:structural report-error tool-package-pins licenses
• CI

Resolves CL-7467

[linear-code]

CL-7467