core: expose matchContextGraphAssertionUri matcher instead of the half-inverse parseContextGraphAssertionUri

[Jurij89]

Context

Follow-up from PR #1780 (GH#1778). The PR added parseContextGraphAssertionUri(subject) in packages/core/src/constants.ts, an inverse of contextGraphAssertionUri(...).

Because a context-graph ID may itself contain / (wallet-scoped IDs like 0xabc…/project, permitted by validateContextGraphId) and an optional sub-graph name is also slash-joined, the inverse cannot recover (contextGraphId, subGraphName) from the subject alone. The helper therefore returns a single conflated scope field, and every consumer must compare scope against subGraphName ? contextGraphId + "/" + subGraphName : contextGraphId themselves. The parser is correct (right-anchored on /assertion/<addr>/<name>), but the API name implies a clean inverse that does not exist, and it leaks the grammar into callers.

Suggested refinement (non-blocking, maintainability)

Add a matcher that keeps the unavoidable ambiguity local to core:

matchContextGraphAssertionUri(
  subject: string,
  expected: { contextGraphId: string; subGraphName?: string; name: string },
): { agentAddress: string } | undefined

It returns the author address only when the subject matches the full expected coordinate. This collapses contextGraphAssertionQueryBounds + parse-and-compare into one canonical helper and removes the ambiguous scope from the consumer-facing surface.

Pointers

• packages/core/src/constants.ts — parseContextGraphAssertionUri, contextGraphAssertionQueryBounds, contextGraphAssertionUri
• Consumers: packages/agent/src/finalized-assertion-author.ts, packages/agent/src/sync/durable-integrity.ts

Filed as a non-blocking maintainability follow-up from PR #1780 review.

[Jurij89]

Closing as won't-do — re-checked against current testnet-canary and the premise does not hold up.

The concern was that parseContextGraphAssertionUri is an ambiguous "half-inverse" that could misparse a contextGraphId containing a slash. In the current implementation (packages/core/src/constants.ts:357-378) the parse is right-anchored on the last three segments, so it parses correctly for every reachable input, slash-containing cgIds included. The one theoretically ambiguous pair is additionally fenced by distinct _meta graphs (packages/agent/src/finalized-assertion-author.ts:59), and every consumer already compares the parsed scope before trusting it (:105-107).

So there is no latent correctness bug here, only a naming/shape preference — and the migration would churn core/src/constants.ts, assertion-seal.ts and sync/durable-integrity.ts, which are the same surfaces #1936/#1940/#1943 have been touching.

Also relevant to why this is no longer worth its own PR: it was filed as an enabler for #1786, and #1786 does not need it — contextGraphAssertionQueryBounds plus the existing scope comparison already does that job. If the matcher is still wanted it can be folded in opportunistically while #1786 is in that code, rather than as a standalone refactor.