ci(release): build release candidates with the release profile

[jacderida]

Linear issue

V2-868 — https://linear.app/autonominetwork/issue/V2-868/stop-using-debug-builds-for-the-release-candidate

Risk tier

• T0 — docs / tooling / CI / pure UX-output. Repo CI only.
• T1 — client-only, no network-facing behavior change. CI + prod compat smoke.
• T2 — node/client logic with behavioral surface, no protocol/format/economics change. Dev testnet + ADR.
• T3 — protocol / storage format / payments / routing. T2 evidence + adversarial testing.

Compatibility

• Wire: none — no source changes, no protocol surface touched.
• Storage: none.
• API: none — the crate's public API is unchanged; only CI build flags and a comment.

Semver impact

• breaking
• feature
• fix

Test evidence

Per T0, repo CI plus local verification of the build the workflow now performs:

• .github/workflows/release.yml parses as valid YAML.
• cargo build --release succeeds (5m43s). Output is ELF 64-bit LSB pie executable, stripped, 19M — a genuine release artifact.
• cargo fmt --all -- --check clean.
• Logging confirmed present in a release-profile binary. Ran the built binary with --enable-logging --log-level debug; it emitted INFO and DEBUG records normally. This is the crux of the issue — the debug build was never what enabled logging.
• No profile_dir / build_flags / debug references remain in the release workflow.
• is_prerelease retains both of its other uses: gating the crates.io publish job and setting the GitHub pre-release flag.
• Archive asset names (ant-node-cli-<friendly_name>.tar.gz|zip) unchanged across all five matrix targets, so downstream consumers — testnet deployment, auto-upgrade, canaries — are unaffected.

Why the original reasoning is obsolete

Two independent reasons:

1. default = ["logging"], so the production flag set --release --no-default-features --features logging resolved to exactly the default feature set. Logging was never actually stripped from production builds.
2. Logging is gated at runtime by --enable-logging / ANT_ENABLE_LOGGING, not by the build profile. Whether an RC logs was never a build-time decision.

Issue step 2 ("find a route that does not require a debug build") therefore needs no work — that route already exists and is the one operators use.

New dependency

none

ADR

n/a — Tier 0.

Mitigation / rollback

Single-commit revert of a CI workflow change; it affects nothing until the next release run. If an RC built this way proves problematic, revert and the following RC is a debug build again. Note the intended consequence: RC binaries are now stripped, so panic backtraces lose function names — exactly as production behaves today.

[dirvine]

Reviewed exact head 817e826ee27bf77cf1ab559d4da24fb686c92c10.

The release workflow now consistently builds and archives the release profile for both release candidates and final releases. I verified that:

• the removed profile_dir / build_flags outputs have no stale references;
• is_prerelease retains its publishing and GitHub pre-release uses;
• logging remains in the default feature set;
• the workflow parses as valid YAML;
• the diff has no whitespace errors;
• all current CI checks pass across Linux, macOS and Windows, including the no-logging build and security audit.

No blocking issues found. Approved.