fix(relay): stop charging worker startup to the authored source deadline

[jeremi]

Two independent changes.

fix(relay): stop charging worker startup to the authored source deadline

public_rhai_commands_accept_the_released_contract_for_an_unknown_product
failed on protected main against a tree byte-identical to the one that had
just passed on the pull request head:

health-record.partial-child-health-evidence::derived/request_authority
(derived_error_mismatch: expected=fixture.request_mismatch,
 actual=fixture.execution_contract_invalid)

The offline fixture runner built its hard deadline from the authored operation
deadline alone (deadline: 8s for that integration). That deadline bounds a
source call, but offline there is no source, so the same budget also had to
cover starting the Rhai worker process and compiling the script before the
mismatched request was issued. WorkerProcess::evaluate already adds
WORKER_STARTUP_GRACE to the deadline it builds for itself, and the
debug-build value exists because process start in a debug build is slow; the
fixture runner did not add it. The child still enforces its own script limits,
so this widens no script budget.

run_rhai_worker also collapsed every WorkerError into
ExecutionContractViolation, so running out of wall clock was reported as the
compiled plan being violated. That is what made a transient stall read as a
defect in a correct fixture. A timeout now reports the existing
source.deadline_exceeded class.

Confidence caveat. The failing test is #[cfg(target_os = "linux")] and was
not reproduced directly; the diagnosis is inferred from the code path. Three
WorkerError variants reach that line without the host having recorded a
terminal error: TimedOut, SpawnFailed, and IpcFailed. Every other variant
is deterministic given the same inputs and is ruled out by the green run on the
identical tree. This fixes and reclassifies TimedOut. If the cause was
actually SpawnFailed, a recurrence is still reported as a plan violation.
Extending OfflineFixtureError with a harness-failure class would change a
documented stable diagnostic set and is left as a separate decision.

Two tests, both confirmed failing without the change.

feat(evidence): publish manual development builds of the toolset from main

A manually dispatched workflow builds the three binaries for Linux amd64, Linux
arm64, and macOS arm64 from a protected-main revision that already passed CI,
and publishes them as a prerelease tagged
v<workspace-version>-dev.<run>.<attempt>. The installer accepts that tag shape
and, when it sees one, replaces the release verification pointer with an
explicit statement that the checksums are unsigned, no authenticity check was
performed, and the build is not a Registry Stack release.

Release-provenance review notes are in the commit message. In summary: the
workflow is workflow_dispatch only and main only, requires a successful
push-event CI run for the exact SHA, proves the tag is absent as both a git
tag and a release before building, carries contents: write in one job that
does not check out the repository, publishes with --prerelease --latest=false
against the validated SHA, and contains no gh release upload,
gh release delete, --clobber, git push, or git update-ref. The gate
inventory forbids those returning.

Verification

Gate	Result
cargo fmt --check	OK
cargo clippy --locked --workspace --all-targets -- -D warnings	clean
cargo test --locked -p registry-relay	30 result lines, 0 failed
cargo test --locked -p registryctl	28 result lines, 0 failed
cargo test --locked -p registry-evidencectl --test install_script	19 passed
python3 -m unittest release.scripts.test_release_workflow_structure release.scripts.test_check_gates_inventory	95 tests, OK
python3 release/scripts/check-gates-inventory.py	149 gates passed
shellcheck and shfmt -d on install.sh	clean
REGISTRY_RELEASE_SOURCE_MODE=monorepo release/scripts/check-release-source-model.sh	exit 0
python3 -m unittest release.scripts.test_registry_release	OK

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 18b0c467e6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Bind the dev release tag before publishing

If a repository writer creates the run-derived ${tag} after the validate job's absence check but before this publish step, gh release create will attach the release to that existing tag; per gh release create --help, --target only affects automatic tag creation when the tag is absent. That can publish assets and notes claiming ${source_sha} while the public release/tag resolves to another commit, breaking the provenance guarantee for these development builds; create/verify the tag binding atomically, or use a pre-created verified tag with --verify-tag, before exposing the release.

Useful? React with 👍 / 👎.