Derive the advertised dictyon client version from package metadata

[forkwright]

Finding

Every registration and map request advertises GoVersion: "dictyon/0.1.0" from a hardcoded string, while the live workspace and dictyon package are version 0.2.0.

The wire type's own documentation repeats the stale value, so runtime behavior and API guidance have already drifted together from the package authority.

Verified against main 9aa9a56223afdd47d7723104cd16a5c07d5fc722.

Evidence

• Root Cargo.toml:8-13 sets [workspace.package] version = "0.2.0"; crates/dictyon/Cargo.toml inherits version.workspace = true.
• crates/dictyon/src/control/mod.rs:420-435 constructs request Hostinfo with go_version: "dictyon/0.1.0". Both build_register_requestandbuild_map_request` call this helper, so every control request carries the stale value.
• crates/mitos/src/types/mod.rs:145-165 documents Hostinfo.go_version by saying dictyon sends "dictyon/0.1.0", creating a second maintained declaration of the same version identity.
• Unit and serialization fixtures also pin the literal rather than deriving it, so a package release does not make a test fail merely because the advertised identity stayed behind.
• A targeted all-state issue search found no existing owner for the stale GoVersion identity. Release automation issues such as the historical internal-dependency/lock drift do not cover runtime protocol metadata.

Why this matters

The control server uses Hostinfo for display, diagnostics, compatibility analysis, and capability negotiation context. A 0.2.0 client presenting itself as 0.1.0 makes captured traces and server-side reports attribute behavior to the wrong release.

That is especially damaging while Phase A interoperability is under independent verification: an oracle receipt or server log can appear to prove one released implementation while the bytes actually came from another.

The current drift also guarantees recurrence. Every future release requires somebody to remember an unrelated private string in control code and its repeated documentation.

Desired correction

Make the dictyon package version the sole authority for the implementation identifier, for example through a crate-local constant derived from env!("CARGO_PKG_VERSION") and a canonical Hostinfo constructor.

The protocol field may retain its upstream name GoVersion; only the value's ownership changes. Human-facing documentation should describe the derived format rather than restate a concrete version.

Done when:

• the advertised value is derived as dictyon/<dictyon package version>;
• register and map requests consume one shared constructor/value;
• no concrete dictyon version literal remains in production source or API documentation;
• serialization tests derive their expectation from package metadata while still asserting the exact wire string; and
• changing the workspace/package version changes the advertised identity without another source edit.