Publish the contextgraph 2.0.0 crates to crates.io (crates-io environment + token are not set up)

[macanderson]

The workspace froze the protocol at contextgraph/1.0 (#77) and has since moved to 2.0.0 (#87), but crates.io still serves 0.1.2 — the release workflow is inert because the crates-io GitHub Environment and CARGO_REGISTRY_TOKEN secret do not exist (repo Settings shows only Preview/Production). Until the publish lands, stella pins =0.1.2 and its protocol tripwire spans both wire strings (stella#5482).

Human, one-time steps (per PUBLISHING.md and the release workflow header):

1. Create the crates-io environment with required reviewers in repo Settings.
2. Add CARGO_REGISTRY_TOKEN scoped to that environment.
3. Push a contextgraph-v2.0.0 tag and click Approve and deploy.

Follow-up once published: bump stella's contextgraph pins off 0.1.x and delete the draft entry from the protocol tripwire.

Definition of done

• crates-io environment + token exist
• contextgraph 2.0.0 crates published (types -> host -> conformance -> trace)
• stella pins bumped off 0.1.x and the tripwire's draft entry deleted
• Downstream Canary green against both the release and HEAD

[macanderson]

One correction: stella#5482 is still open

The body reads "stella pins =0.1.2 and its protocol tripwire spans both wire strings (stella#5482)", which parses as already true. It is not yet:

gh pr view 5482 --repo macanderson/stella
  #5482 OPEN merged=null   test(contextgraph): span the protocol tripwire across the CGP 1.0 freeze

stella's origin/main today still has the single-valued assertion:

// crates/stella-cli/src/contextgraph/tests.rs
assert_eq!(contextgraph_types::PROTOCOL_VERSION, "contextgraph/1.0-draft", …)

So the Downstream Canary is red right now and stays red until that PR merges — which it can do independently of everything in this issue, since spanning both strings works against published 0.1.2 and against CGP HEAD alike.

Worth stating on the issue because the two are easy to conflate: merging stella#5482 fixes the canary, and only the publish fixes the pin. The last DoD box here ("Downstream Canary green against both the release and HEAD") depends on both.

Confirmed the blocker in the body, for the record: main has no branch protection and no rulesets, and the repository's environments do not include crates-io, so release.yml's publish job cannot run even on a correctly-shaped tag. Steps 1 and 2 really are human repo-Settings actions that nothing in the tree can perform.

Related: #103 tracks the fact that no published version has a git tag at all and three tag conventions disagree — step 3 here pushes contextgraph-v2.0.0, which is the convention release.yml triggers on, so landing this also settles which convention wins.

[macanderson]

Registry survey carried over from #97 (now closed as a duplicate of this issue)

Every registry queried directly on 2026-08-29. Two facts here widen this issue's scope, so they are worth having on the ticket rather than in a closed one:

Package	Serves today
contextgraph-types / -host / -conformance / -trace (crates.io)	0.1.2 — published 2026-08-01; 0.1.1 yanked, 0.1.0 live
@contextgraph/sdk (npm)	404 — never published
create-contextgraph-provider (npm)	404 — never published
contextgraph-sdk (PyPI)	0.1.0

Two things this changes about the plan

1. The 1.0 publish never happened. #97, #84 and #16 all assumed crates.io was serving 1.0.0. It went 0.1.0 → 0.1.1 (yanked) → 0.1.2 and has not moved since. So the jump is 0.1.2 → 2.0.0, two majors, not one — and docs/stability.md's instruction to depend on contextgraph-types = "2" currently resolves to nothing, as would "1".

2. Two of the packages have no publish history at all, so their 2.0.0 is a first publish, not a version bump. The runbook does not cover that case. Before the tag push in step 3, worth checking:

• npm scope ownership of @contextgraph — whether the account can publish under it at all;
• name availability for create-contextgraph-provider;
• publishConfig.access on the scoped package, since a scoped npm package defaults to restricted and a 2.0.0 that publishes privately looks successful and is unreachable;
• whether the npm publish belongs in the same approval-gated environment as the crates, or its own.

A first publish failing halfway is also the one-way door release.yml's header already warns about for crates: re-running re-publishes an already-live version, which the registries reject. Worth ordering npm and PyPI explicitly in the runbook the way the four crates already are.