Runtime package: use org-fork for publish rehearsal and post-publish verification

[svelderrainruiz]

Problem

The org fork is a poor generic throughput lane because its PR surface still pulls in self-hosted Windows and host-Docker jobs, but it is still the only realistic rehearsal plane for package publication that must exercise the LabVIEW-Community-CI-CD owner namespace.

That matters for the new runtime package surface:

• packages/runtime-harness/package.json is scoped as @labview-community-ci-cd/runtime-harness
• personal forks can exercise hosted PR iteration, but they cannot prove org-owned package publication or org-owned post-publish install flows
• today there is no explicit lane that uses the org fork for package publish rehearsal and post-publish verification, so origin is either underused or misused as a generic PR lane

Goal

Repurpose the org fork as the package publication rehearsal and post-publish verification plane for the runtime-harness package surface instead of treating it as a generic hosted fork lane.

Scope

• define the publish rehearsal contract for @labview-community-ci-cd/runtime-harness
• add an org-fork execution path that can pack/publish a candidate package through an org-owned namespace or equivalent publish staging surface
• add deterministic post-publish verification that installs the published candidate into a clean consumer context and proves the expected exports work
• keep this lane isolated from self-hosted VI/history checks so org-fork package rehearsal remains hosted-first and purpose-built
• record the lane role explicitly so future agents use origin for package publish/verify work, not generic hosted PR throughput

Acceptance criteria

• there is a checked-in workflow/helper path that uses the org fork specifically for runtime-harness package publish rehearsal
• the rehearsal path produces machine-readable publish evidence (package identity, version, registry/target, provenance artifact paths)
• a post-publish verification step installs the published candidate in a clean consumer context and verifies the package exports/import surface
• the org-fork package path runs without depending on the self-hosted Windows/host-Docker checks that block normal PR throughput
• docs/runbooks state that personal fork is the fast hosted code-iteration lane, while org fork is reserved for org-namespace package publish/verification

Notes

• This does not make the org fork the default feature-iteration lane again.
• This is specifically about package publication and post-publish verification for the new runtime-harness package surface.
• Current related blocker: Fork self-hosted Windows jobs can remain queued without eligible runner admission compare-vi-cli-action#991 shows why org-fork is not fit for generic hosted throughput today.

[svelderrainruiz]

Closing this stale mirror after widening upstream LabVIEW-Community-CI-CD#1006 into an org-fork release-plane epic. The executable origin lane moved to child issue LabVIEW-Community-CI-CD#1007 instead.