service.version reads bare 3.7.0 on a .438 nightly: the informational version never receives the nightly stamp #3455

First live reading of #3453's service block, taken minutes after it shipped: on a store running the 3.7.0-nightly.20260915.438 build, service.version reads bare 3.7.0 — no prerelease, no nightly stamp. Same reading on all three stores that installed that nightly tonight.

The MCP read is faithful to the assembly: it surfaces AssemblyInformationalVersionAttribute through the same method the CLI's version command uses, stripping only + build metadata. So the miss is upstream — the nightly's version stamping evidently carries the .438 uniqueness (#3390's whole point) somewhere the informational version is not, or the informational version is 3.7.0+<sha> and the stamp never enters the attribute at all. compiled_schema_version disambiguated tonight's two candidate builds (121 vs 122), but the NEXT same-schema pair of nightlies will be indistinguishable from this field — which is precisely the question the block exists to answer.

Acceptance: on a nightly build, service.version matches the artifact stamp (3.7.0-nightly.20260915.438 for tonight's), so two same-day nightlies read differently, and a release build keeps reading its clean release string. Where to fix — the nightly workflow's version-set step or the property it writes — is the lane's to determine; the MCP read itself should not special-case anything.