[release]: publish CompareVI.Tools bundle with native vi-history capability contract

[svelderrainruiz]

Summary\n\nThe template distributor slice for LabviewGitHubCiTemplate#16 is now in PR flow and stamps a local distributed vi-history capability manifest into generated repositories.\n\n## Gap\n\nThe latest published CompareVI.Tools release pin used by the template (�0.6.3-tools.14) predates the merged producer-contract changes from #1875 / PR #1876, so the release bundle itself is not yet the authoritative published source for consumerContract.capabilities.viHistory.\n\n## Objective\n\nPublish the next CompareVI.Tools bundle so downstream distributors can resolve the vi-history capability natively from the producer release manifest instead of relying on a distributor-local bridge.\n\n## Acceptance\n\n- published CompareVI.Tools release manifest includes consumerContract.capabilities.viHistory\n- published bundle preserves the existing consumer contract paths used by the template scaffold\n- template pin can advance from bridge mode to producer-native capability mode without changing the lightweight distribution model\n\n## Rationale\n\nThis keeps the supply chain coherent:\n\n- compare publishes the capability\n- template distributes the capability\n- generated repos consume the published producer contract\n

[svelderrainruiz]

Queued from template PR #17 after the vi-history distributor slice landed. This stays open as the producer-release follow-up, but it is intentionally non-standing because compare already has an active standing lane.

[svelderrainruiz]

Working the producer-native bundle slice now that #1880 is merged. The patch extends CompareVI.Tools bundle certification so the extracted release archive proves the vi-history distributor contract natively for downstream consumers like LabviewGitHubCiTemplate.

[svelderrainruiz]

Validated the producer-native bundle certification slice on current develop. The patch now extends CompareVI.Tools bundle certification so the extracted release archive proves the vi-history distributor contract natively, including comparevi-tools-release.json presence, authoritative consumer pin resolution, and contract-path resolution for downstream distributors like LabviewGitHubCiTemplate. Proof artifact: tests/results/_agent/release/1877-native-bundle-proof/comparevi-history-bundle-certification.json

[svelderrainruiz]

PR is live: #1881. Auto-merge is enabled, and the hosted tail is running on the current head. The Validate run now includes the updated comparevi-history-bundle-certification lane that attests the extracted CompareVI.Tools bundle is producer-native for downstream vi-history distribution.

[svelderrainruiz]

PR #1881 merged, so the source-level producer-native vi-history contract is now certified in-tree. The standing gap is now narrower and concrete: the latest published CompareVI.Tools bundle is still �0.6.3-tools.14, while �0.6.4-rc.1 only exists as an untagged draft release object with no assets. I’m taking the next slice on compare itself to align the standard release path with actual tag-driven publication, so the next published bundle can carry consumerContract.capabilities.viHistory natively instead of leaving the release flow one step short of
elease.yml.

[svelderrainruiz]

I inspected the live release path from a clean upstream/develop lane.

Findings:

• The latest published tools bundle is still v0.6.3-tools.14.
• v0.6.4-rc.1 exists only as an untagged draft release object (gh release view shows draft/no assets; GitHub has no refs/tags/v0.6.4-rc.1).
• release.yml only publishes on tag pushes (on.push.tags: v*).
• release:finalize still stops at gh release create --draft and does not create/push the signed annotated tag that actually triggers publication.
• priority:release:conductor can create a signed tag only in apply mode, but today it remains proposal-only (RELEASE_CONDUCTOR_ENABLED=0) and does not push/publish the tag path end-to-end.

Dry-run status on clean current upstream/develop:

• node tools/priority/create-release-branch.dryrun.mjs 0.6.3-tools.15 -> PASS
• node tools/priority/finalize-release.dryrun.mjs 0.6.3-tools.15 -> PASS (after the dry branch step creates the local release ref)

But that does not make 0.6.3-tools.15 the honest next live cut, because current develop is already at 0.6.4-rc.1, changelog/docs are aligned to v0.6.4-rc.1, and a new 0.6.3-tools.15 branch from that tip would back-version the release surfaces.

So the smallest honest next slice on compare is a control-plane slice: add a deterministic post-finalize signed-tag publication helper (with dry-run) and wire the release runbook/handoff to use it. Then use that helper to publish the next bundle from the current v0.6.4-rc.1-aligned tip instead of relying on the current untagged draft-release dead end.