chore: release v0.3.0 (lockstep) + sibling dep refresh

[LanNguyenSi]

Summary

Lockstep release of the four version-locked library packages plus a same-PR refresh of the three sibling packages whose pinned-exact deps would otherwise drift.

Package	Old	New	Reason
@lannguyensi/grounding-wrapper	0.2.0	0.3.0	New behavior (see CHANGELOG)
@lannguyensi/evidence-ledger	0.2.0	0.3.0	Lockstep, no code change
@lannguyensi/claim-gate	0.2.0	0.3.0	Lockstep, no code change
@lannguyensi/hypothesis-tracker	0.2.0	0.3.0	Lockstep, no code change
@lannguyensi/grounding-mcp	0.3.0	0.3.1	Pinned deps refresh (+ PACKAGE_VERSION constant)
@lannguyensi/grounding-sdk	0.1.0	0.1.1	Pinned deps refresh
@lannguyensi/review-claim-gate	0.1.0	0.1.1	Pinned deps refresh

Why grounding-wrapper bumps minor

Two PRs landed today on grounding-wrapper:

• fix(grounding-wrapper): set phase_status['complete'] to 'done' on terminal transition #97 (task 9a258d6d): phase_status['complete'] is now set to 'done' on terminal transition, so summarizeSession over MCP no longer emits a shape where current_phase: 'complete' disagrees with phase_status.complete: 'pending'.
• feat(grounding-wrapper): validate keyword input on initSession #98 (task 7db33828): exported validateKeyword + wired into initSession. Empty / whitespace-only / pure-Unicode / oversize keywords now throw instead of silently emitting degenerate ids like gs--<ts>. Mixed inputs with at least one ASCII alphanumeric after slug normalisation (e.g. "クラウド-monitor" → "monitor") still pass.

The validateKeyword throws are technically a behavior change (previously-accepted inputs now throw), which warrants the MINOR bump per semver. Grep across the monorepo confirmed every existing initSession( caller uses a valid keyword; no internal regressions.

Why the siblings bump in this PR

grounding-mcp, grounding-sdk, review-claim-gate had pinned exact "0.2.0" deps on the lockstep set. Bumping lockstep alone causes npm to fetch 0.2.0 from the registry (workspace can't satisfy "0.2.0" once it's 0.3.0), producing dev-environment drift where source has 0.3.0 but installs run against 0.2.0. Per memory feedback_workspace_release_mechanics, pinned-exact cross-workspace deps force this kind of paired bump.

grounding-mcp also updates its in-source PACKAGE_VERSION constant (the cli-version test pins it to match package.json).

Lockfile

package-lock.json is regenerated. The -2214-line net delta is consolidation of pre-existing duplicate nested deps (npm normalises during clean regen), not new dep churn from this release. Spot-check confirmed all 12 workspace packages remain as workspace symlinks ("link": true) and there are zero stale 0.2.0 lockstep entries.

Test plan

• npm run build:deps — clean
• All 7 affected packages: 234/234 tests pass (42 grounding-wrapper, 57 evidence-ledger, 22 claim-gate, 26 hypothesis-tracker, 29 grounding-mcp, 12 grounding-sdk, 46 review-claim-gate)
• Dogfood smoke via node REPL: happy path + 4 sad paths + Mixed-Unicode acceptance + grounding-mcp --version returns 0.3.1
• Review subagent: APPROVE, full scope-discipline + cross-repo backward-compat check
• No other repo under /home/lan/git/pandora/ pins 0.2.0 on these packages
• CI green
• Merge-approval gate (ledger fact + labels)

Post-merge tag sequence

Push tags one at a time (per memory feedback_bulk_tag_push_workflow):

git tag v0.3.0 && git push origin v0.3.0
# wait for publish-npm.yml + verify on npm
git tag grounding-mcp-v0.3.1 && git push origin grounding-mcp-v0.3.1
git tag grounding-sdk-v0.1.1 && git push origin grounding-sdk-v0.1.1
git tag review-claim-gate-v0.1.1 && git push origin review-claim-gate-v0.1.1

The three sibling tags must wait for the lockstep set to appear on npm, because their own publish workflow runs npm install and would otherwise fetch stale 0.2.0 deps.