fix(deps): pin Koinon to a released tag instead of tracking main

[forkwright]

Finding

Hamma's workspace dependency uses a moving branch:

koinon = { git = "https://github.com/forkwright/koinon", branch = "main" }

Koinon published v0.1.0 on 2026-07-08, but Hamma still follows main; the current lockfile happens to pin commit 73179b9c.... A lockfile refresh can therefore absorb unrelated Koinon changes without an explicit dependency decision.

Evidence

• Workspace Cargo.toml: koinon = { git = "https://github.com/forkwright/koinon", branch = "main" } — a moving-branch dependency, not a tag.
• Koinon released v0.1.0 on 2026-07-08 — a pinnable, immutable target already exists.
• Cargo.lock currently resolves the branch to commit 73179b9c... — pinned only incidentally, by whatever main happened to be at last lock refresh.

Why this matters

This conflicts with the fleet's established cross-repo contract of consuming immutable release tags. A branch = "main" dependency means any future cargo update can silently absorb unrelated Koinon changes into Hamma's build with no explicit dependency decision or review point.

Desired correction

Pin the workspace dependency to the verified compatible Koinon release tag. If Hamma requires unreleased behavior, release that behavior in Koinon first rather than using a branch dependency.

Done when:

• Cargo.toml uses an immutable Koinon tag.
• Cargo.lock resolves from that tag.
• CI validates the tag-pinned dependency.
• A dependency policy check rejects new fleet-internal branch = "main" dependencies.

Surfaced during a 2026-07-21 fleet architecture review.

[forkwright]

Fixed by #73 (merged 2026-07-31). Verified on main via the contents API, not inferred from the
merge — Cargo.toml:45:

koinon = { git = "https://github.com/forkwright/koinon", tag = "v0.1.0" }

Pinned to the released tag rather than a commit sha, so the dependency decision stays legible. A
lockfile refresh can no longer absorb arbitrary upstream Koinon changes without an explicit bump.

Verified to build before merge with cargo check --workspace --all-targets, which covers the
koinon::telemetry import in dictyon/examples/connect.rs — the pinned tag carries no API gap
against what hamma uses. Full gate passed: fmt, check, clippy -D warnings, nextest 80/80, kanon
lint clean.

This was tracked twice: the same defect was also ARCH/substrate-floating-ref at Cargo.toml:45 in
.kanon-lint-baseline.toml, and that entry was removed in the same PR, so the two records are now
consistent.

Noted but out of scope: deny.toml still carries allow-git = ["https://github.com/forkwright/koinon"].
That exception is less load-bearing now the dependency is tag-pinned, but removing it would need the
git dependency itself replaced by a registry release.

[forkwright]

Reopened because the issue's manifest/lock acceptance has regressed on current GitHub main.

Fresh canonical reads show:

• root Cargo.toml:45 requests forkwright/koinon at tag v0.2.0;
• Cargo.lock:702-704 still resolves koinon 0.1.0 from tag v0.1.0;
• the only source use found is crates/dictyon/examples/connect.rs:16, so this is development/example use rather than proved full-bootstrap production adoption.

The immutable-tag decision remains correct. Restore manifest/lock coherence, gate it, and keep the edge classified as example/dev-only until a production binary adopts Koinon's integrated bootstrap. Kanon's substrate registry now records that distinction rather than promoting the declaration into stable adoption.