H: generalize ungated capability request/grant as a native core/management primitive

[Mearman]

Parent: #28

core/room's room.join/room.invite (spec/room.cddl:126-155) hand-built the ungated-request-then-human-approves-then-mint-and-return-token flow for one scope kind. This generalizes it into a domain-agnostic primitive any capability can use, adds the timeout handling neither room.join nor agent-comms' connect_request currently has, then migrates room.join/room.invite onto it rather than leaving two parallel implementations of the same idea.

Sub-issues below cover the wire addition (capability-request/capability-grant-ok), a queryable canGrant() helper pulled out of mintCapabilityToken's own narrowing check, requester- and receiver-side timeouts for any held-open manage-request, an optional valid-until field reusing the message/token-lifetime mechanism from section E, and the migration of room.join/room.invite onto the new primitive.

Extended by a further design pass into three more pieces, no longer deliberately deferred:

• core/tokens: replace hardcoded narrowing checks with a generic predicate-list evaluator (trilean-backed) #85 -- fold the hardcoded narrowing checks (bearer, scope, expires, delegations-remaining) and the informal extension-tail convention into one generic conditions: [* PredicateNode] list, evaluated by a single trilean-backed evaluator. This is what an approver narrowing a request beyond plain scope containment (a specific capability at a specific scope, plus an arbitrary extra condition) actually needs -- e.g. approving a narrower capability than requested with an additional condition attached, which the flat hardcoded-fields model can't express without inventing a new field every time.
• core/tokens: separate delegation-depth-remaining from an issuer's own root-minting authority #86 -- fix delegations-remaining conflating "hops remaining below this token" with "may this token be used to mint further root-level grants", the real bug found implementing agent-comms' own room-owner grant.
• core/room (gossip): advertise delegable-grant candidates in peer-advert for request routing #87 -- gossip-advertised delegable-grant candidates for request routing, the piece originally deferred here as its own design question; now scoped and filed since a concrete shape exists.

A request/approval round trip stays single-round-trip even for a narrowed-plus-conditioned grant: the approver mints and returns a token for whatever it's actually willing to give (narrower capability, added conditions), and the requester's own decision to use or discard that token is what stands in for "accept the counter-offer" -- no separate negotiation protocol needed on top of the existing mechanism.

---

PR #93 opened: the wire shape for #78 (capability-request/capability-grant-ok) is now added to core/management. Migrating room.join/room.invite onto it, and the canGrant/canSatisfy check, timeouts, and valid-until field it unblocks (#79-#83), remain open follow-up work.