feat(resolver): Stabilize min-publish-age - #17335

As identified at rust-lang#17335 (comment)

### What does this PR try to resolve?

As identified at
rust-lang#17335 (comment)

### How to test and review this PR?

# `[registry]` vs `[registries.<name>]` per-key semantics

Review notes for [rust-lang#17335] (min-publish-age stabilization),
comparing how each config key behaves across the two tables.
Verified against PR head `7b009184` with repro tests in
`tests/testsuite/registry_table_confusion.rs`
and the PR's own `tests/testsuite/min_publish_age.rs`.

[rust-lang#17335]: rust-lang#17335 (comment)

| Key | `[registry]` | `[registries.crates-io]` | `[registries.<alt>]` | Evidence |
|---|---|---|---|---|
| `token` | works for crates.io; does **not** follow `registry.default` | **silently ignored** (config and `CARGO_REGISTRIES_CRATES_IO_TOKEN` env) | works | `registries_crates_io_token_ignored_for_crates_io`, `registry_token_does_not_follow_registry_default` |
| `credential-provider` | works for crates.io | **silently ignored** | works | `registries_crates_io_credential_provider_ignored` |
| `secret-key` / `secret-key-subject` | works for crates.io | silently ignored (same code path as `token`) | works | code: `src/util/auth/mod.rs:212` returns `[registry]` for crates.io before any name lookup |
| `min-publish-age` (new) | crates.io only; ignored for alt registries even with `registry.default` pointing at them | **honored; overrides `registry.min-publish-age`** | honored | `registry_alt_ignores_min_publish_age`, `registries_crates_io_overrides_registry_default` |
| `global-min-publish-age` (new) | fallback for **all** registries | silently ignored (not a `RegistryConfig` field) | silently ignored | code: `src/context/schema.rs:530` |
| `protocol` | silently ignored (not a `GlobalRegistryConfig` field) | honored | parsed but unused (`_protocol`) | code: `SourceId::crates_io_is_sparse` reads `registries.crates-io.protocol` only |
| `index` | hard error: "no longer supported" | silently ignored (`SourceId::alt_registry` short-circuits `crates-io`) | required; defines the registry | code: `check_registry_index_not_set`, `src/workspace/source_id.rs:296` |
| `default` | selects target registry for `publish`/`login`/`owner`/`yank` when `--registry`/`--index` absent | silently ignored | n/a | code: `src/util/command_prelude.rs:919` |
| `global-credential-providers` | fallback providers for **all** registries | silently ignored | silently ignored | code: `src/util/auth/mod.rs:57` |

Key asymmetries:

* `min-publish-age` is the first key where `[registries.crates-io]` both works
  and overrides its `[registry]` counterpart;
  for the auth keys, `[registries.crates-io]` is dead config.
* Auth resolves crates.io **by URL first** (`is_crates_io()`, `src/util/auth/mod.rs:212`);
  min-publish-age resolves **by name first** (`alt_registry_key()`, `src/resolver/version_prefs.rs:279`).
  A named mirror of crates.io's index gets `[registry]` credentials
  but `registries.<mirror>.min-publish-age`.
* `registries.<name>.global-min-publish-age` and `registry.protocol` are silent no-ops —
  the same "subtle `s` distinction" concern raised in
  [rust-lang#12334](rust-lang#12334 (comment)).

# `[registry]` vs `[registries.<name>]` per-key semantics

Review notes for [rust-lang#17335] (min-publish-age stabilization),
comparing how each config key behaves across the two tables.
Verified against PR head `7b009184` with repro tests in
`tests/testsuite/registry_table_confusion.rs`
and the PR's own `tests/testsuite/min_publish_age.rs`.

[rust-lang#17335]: rust-lang#17335 (comment)

| Key | `[registry]` | `[registries.crates-io]` | `[registries.<alt>]` | Evidence |
|---|---|---|---|---|
| `token` | works for crates.io; does **not** follow `registry.default` | **silently ignored** (config and `CARGO_REGISTRIES_CRATES_IO_TOKEN` env) | works | `registries_crates_io_token_ignored_for_crates_io`, `registry_token_does_not_follow_registry_default` |
| `credential-provider` | works for crates.io | **silently ignored** | works | `registries_crates_io_credential_provider_ignored` |
| `secret-key` / `secret-key-subject` | works for crates.io | silently ignored (same code path as `token`) | works | code: `src/util/auth/mod.rs:212` returns `[registry]` for crates.io before any name lookup |
| `min-publish-age` (new) | crates.io only; ignored for alt registries even with `registry.default` pointing at them | **honored; overrides `registry.min-publish-age`** | honored | `registry_alt_ignores_min_publish_age`, `registries_crates_io_overrides_registry_default` |
| `global-min-publish-age` (new) | fallback for **all** registries | silently ignored (not a `RegistryConfig` field) | silently ignored | code: `src/context/schema.rs:530` |
| `protocol` | silently ignored (not a `GlobalRegistryConfig` field) | honored | parsed but unused (`_protocol`) | code: `SourceId::crates_io_is_sparse` reads `registries.crates-io.protocol` only |
| `index` | hard error: "no longer supported" | silently ignored (`SourceId::alt_registry` short-circuits `crates-io`) | required; defines the registry | code: `check_registry_index_not_set`, `src/workspace/source_id.rs:296` |
| `default` | selects target registry for `publish`/`login`/`owner`/`yank` when `--registry`/`--index` absent | silently ignored | n/a | code: `src/util/command_prelude.rs:919` |
| `global-credential-providers` | fallback providers for **all** registries | silently ignored | silently ignored | code: `src/util/auth/mod.rs:57` |

Key asymmetries:

* `min-publish-age` is the first key where `[registries.crates-io]` both works
  and overrides its `[registry]` counterpart;
  for the auth keys, `[registries.crates-io]` is dead config.
* Auth resolves crates.io **by URL first** (`is_crates_io()`, `src/util/auth/mod.rs:212`);
  min-publish-age resolves **by name first** (`alt_registry_key()`, `src/resolver/version_prefs.rs:279`).
  A named mirror of crates.io's index gets `[registry]` credentials
  but `registries.<mirror>.min-publish-age`.
* `registries.<name>.global-min-publish-age` and `registry.protocol` are silent no-ops —
  the same "subtle `s` distinction" concern raised in
  [rust-lang#12334](rust-lang#12334 (comment)).

…td legs

Pins Rust to an exact nightly-2026-08-20 across every CI workflow (was
floating on dtolnay/rust-toolchain@stable). Nightly, not stable 1.98.0,
because -Zmin-publish-age -- the cargo dependency-resolution soak
feature .cargo/config.toml already configures -- is still nightly-only:
verified directly against a real 1.98.0 stable binary, which silently
ignores the config with a warning, and against the tracking issue
(rust-lang/cargo#17009), still open. The stabilization PR
(rust-lang/cargo#17335, open) targets Rust 1.100.0, due late September
2026 -- that's the concrete transition-to-stable target, matching
socket-wheelhouse's own canonical rust-toolchain.toml.

Drops the tvOS/visionOS/watchOS Tier-3 build legs entirely from
release-packages.yml -- the nightly + rust-src install steps, the
-Z build-std=core,std,panic_abort build branches, the tier3 matrix
field, and the staging step's per-platform artifact-copy loop.
-Z build-std remains unstable regardless of channel, so this removal
is independent of which channel the pin above uses. The
perry-ui-tvos/visionos/watchos crates stay in the workspace, and the
compiler's own auto-rebuild (perry compile --target tvos-simulator,
via a floating +nightly the end user must have installed -- see
crates/perry/src/commands/compile/link/build_and_run.rs and
crates/perry/src/commands/compile/optimized_libs/driver.rs) is
untouched and still exercised by test.yml's tvOS-sim doc-tests; only
release-packages.yml's build-and-ship leg for these three platforms is
gone.

Applies the newly-stabilized {f32,f64}::algebraic_{add,sub,mul,div,rem}
methods in perry-runtime/src/perf_histogram.rs's stddev() (Node's
perf_hooks Histogram) -- safe because it's an internal HdrHistogram-
bucketed statistic, not a value any spec requires bit-exact evaluation
order for.

Recorded in external-tools.json's rust entry as a soakBypass-adopted
version (published 2026-08-20, adopted 1 day later, removable
2026-08-27).

The newer pinned nightly also surfaces two classes of pre-existing
issues that were invisible under the previous floating stable, both
fixed here: Atomic::fetch_update was renamed to try_update (8 call
sites across gc/barrier, gc/poll_arm, gc/layout_tables,
gc/roots/stack_maps, arena/block -- a pure rename, verified against
the real try_update signature), and an expanded unused-import lint now
catches a redundant `use super::super::*;` sitting alongside `use
super::*;` in 33 files (6 in perry-codegen's node_core native table, 27
in perry-runtime's node_stream_constructors/object modules) -- deleted
each line and confirmed the workspace still builds and 1051 targeted
unit tests still pass.

Verified against the real toolchains, not just docs: installed
nightly-2026-08-20 and (earlier) stable 1.98.0 locally, confirmed
-Zmin-publish-age activates on the former and is silently ignored on
the latter, ran the exact CI `warnings` job commands
(cargo check -p perry --bins, and cargo check --workspace --all-targets
minus the host-incompatible UI crates) under the pinned nightly with
RUSTFLAGS=-D warnings -- both clean -- and ran the perf_histogram test
suite (including Node-oracle-comparison tests) -- all clean.

Addresses CodeRabbit's review: fixed stale "stable" wording in
release-packages.yml comments/step names (including two more Tier-3
mentions CodeRabbit's follow-up review caught in create-release and
publish-assets) and scoped CLAUDE.md's tvOS/visionOS/watchOS claim to
release-packages.yml specifically. Left two items as documented
follow-ups rather than in-scope fixes: the gc-ratchet.yml baseline's
recorded toolchain provenance (metadata only, not enforced by
gc_ratchet.py, needs a real profiling run to regenerate) and
test.yml's/driver.rs's floating +nightly for the Tier-3 auto-rebuild
feature (must track whatever nightly the end user has installed, not
this repo's CI-only pin).

…td legs (#8550)

Pins Rust to an exact nightly-2026-08-20 across every CI workflow (was
floating on dtolnay/rust-toolchain@stable). Nightly, not stable 1.98.0,
because -Zmin-publish-age -- the cargo dependency-resolution soak
feature .cargo/config.toml already configures -- is still nightly-only:
verified directly against a real 1.98.0 stable binary, which silently
ignores the config with a warning, and against the tracking issue
(rust-lang/cargo#17009), still open. The stabilization PR
(rust-lang/cargo#17335, open) targets Rust 1.100.0, due late September
2026 -- that's the concrete transition-to-stable target, matching
socket-wheelhouse's own canonical rust-toolchain.toml.

Drops the tvOS/visionOS/watchOS Tier-3 build legs entirely from
release-packages.yml -- the nightly + rust-src install steps, the
-Z build-std=core,std,panic_abort build branches, the tier3 matrix
field, and the staging step's per-platform artifact-copy loop.
-Z build-std remains unstable regardless of channel, so this removal
is independent of which channel the pin above uses. The
perry-ui-tvos/visionos/watchos crates stay in the workspace, and the
compiler's own auto-rebuild (perry compile --target tvos-simulator,
via a floating +nightly the end user must have installed -- see
crates/perry/src/commands/compile/link/build_and_run.rs and
crates/perry/src/commands/compile/optimized_libs/driver.rs) is
untouched and still exercised by test.yml's tvOS-sim doc-tests; only
release-packages.yml's build-and-ship leg for these three platforms is
gone.

Applies the newly-stabilized {f32,f64}::algebraic_{add,sub,mul,div,rem}
methods in perry-runtime/src/perf_histogram.rs's stddev() (Node's
perf_hooks Histogram) -- safe because it's an internal HdrHistogram-
bucketed statistic, not a value any spec requires bit-exact evaluation
order for.

Recorded in external-tools.json's rust entry as a soakBypass-adopted
version (published 2026-08-20, adopted 1 day later, removable
2026-08-27).

The newer pinned nightly also surfaces two classes of pre-existing
issues that were invisible under the previous floating stable, both
fixed here: Atomic::fetch_update was renamed to try_update (8 call
sites across gc/barrier, gc/poll_arm, gc/layout_tables,
gc/roots/stack_maps, arena/block -- a pure rename, verified against
the real try_update signature), and an expanded unused-import lint now
catches a redundant `use super::super::*;` sitting alongside `use
super::*;` in 33 files (6 in perry-codegen's node_core native table, 27
in perry-runtime's node_stream_constructors/object modules) -- deleted
each line and confirmed the workspace still builds and 1051 targeted
unit tests still pass.

Verified against the real toolchains, not just docs: installed
nightly-2026-08-20 and (earlier) stable 1.98.0 locally, confirmed
-Zmin-publish-age activates on the former and is silently ignored on
the latter, ran the exact CI `warnings` job commands
(cargo check -p perry --bins, and cargo check --workspace --all-targets
minus the host-incompatible UI crates) under the pinned nightly with
RUSTFLAGS=-D warnings -- both clean -- and ran the perf_histogram test
suite (including Node-oracle-comparison tests) -- all clean.

Addresses CodeRabbit's review: fixed stale "stable" wording in
release-packages.yml comments/step names (including two more Tier-3
mentions CodeRabbit's follow-up review caught in create-release and
publish-assets) and scoped CLAUDE.md's tvOS/visionOS/watchOS claim to
release-packages.yml specifically. Left two items as documented
follow-ups rather than in-scope fixes: the gc-ratchet.yml baseline's
recorded toolchain provenance (metadata only, not enforced by
gc_ratchet.py, needs a real profiling run to regenerate) and
test.yml's/driver.rs's floating +nightly for the Tier-3 auto-rebuild
feature (must track whatever nightly the end user has installed, not
this repo's CI-only pin).

…td legs

Pins Rust to an exact nightly-2026-08-20 across every CI workflow (was
floating on dtolnay/rust-toolchain@stable). Nightly, not stable 1.98.0,
because -Zmin-publish-age -- the cargo dependency-resolution soak
feature .cargo/config.toml already configures -- is still nightly-only:
verified directly against a real 1.98.0 stable binary, which silently
ignores the config with a warning, and against the tracking issue
(rust-lang/cargo#17009), still open. The stabilization PR
(rust-lang/cargo#17335, open) targets Rust 1.100.0, due late September
2026 -- that's the concrete transition-to-stable target, matching
socket-wheelhouse's own canonical rust-toolchain.toml.

Drops the tvOS/visionOS/watchOS Tier-3 build legs entirely from
release-packages.yml -- the nightly + rust-src install steps, the
-Z build-std=core,std,panic_abort build branches, the tier3 matrix
field, and the staging step's per-platform artifact-copy loop.
-Z build-std remains unstable regardless of channel, so this removal
is independent of which channel the pin above uses. The
perry-ui-tvos/visionos/watchos crates stay in the workspace, and the
compiler's own auto-rebuild (perry compile --target tvos-simulator,
via a floating +nightly the end user must have installed -- see
crates/perry/src/commands/compile/link/build_and_run.rs and
crates/perry/src/commands/compile/optimized_libs/driver.rs) is
untouched and still exercised by test.yml's tvOS-sim doc-tests; only
release-packages.yml's build-and-ship leg for these three platforms is
gone.

Applies the newly-stabilized {f32,f64}::algebraic_{add,sub,mul,div,rem}
methods in perry-runtime/src/perf_histogram.rs's stddev() (Node's
perf_hooks Histogram) -- safe because it's an internal HdrHistogram-
bucketed statistic, not a value any spec requires bit-exact evaluation
order for.

Recorded in external-tools.json's rust entry as a soakBypass-adopted
version (published 2026-08-20, adopted 1 day later, removable
2026-08-27).

The newer pinned nightly also surfaces two classes of pre-existing
issues that were invisible under the previous floating stable, both
fixed here: Atomic::fetch_update was renamed to try_update (8 call
sites across gc/barrier, gc/poll_arm, gc/layout_tables,
gc/roots/stack_maps, arena/block -- a pure rename, verified against
the real try_update signature), and an expanded unused-import lint now
catches a redundant `use super::super::*;` sitting alongside `use
super::*;` in 33 files (6 in perry-codegen's node_core native table, 27
in perry-runtime's node_stream_constructors/object modules) -- deleted
each line and confirmed the workspace still builds and 1051 targeted
unit tests still pass.

Verified against the real toolchains, not just docs: installed
nightly-2026-08-20 and (earlier) stable 1.98.0 locally, confirmed
-Zmin-publish-age activates on the former and is silently ignored on
the latter, ran the exact CI `warnings` job commands
(cargo check -p perry --bins, and cargo check --workspace --all-targets
minus the host-incompatible UI crates) under the pinned nightly with
RUSTFLAGS=-D warnings -- both clean -- and ran the perf_histogram test
suite (including Node-oracle-comparison tests) -- all clean.

Addresses CodeRabbit's review: fixed stale "stable" wording in
release-packages.yml comments/step names (including two more Tier-3
mentions CodeRabbit's follow-up review caught in create-release and
publish-assets) and scoped CLAUDE.md's tvOS/visionOS/watchOS claim to
release-packages.yml specifically. Left two items as documented
follow-ups rather than in-scope fixes: the gc-ratchet.yml baseline's
recorded toolchain provenance (metadata only, not enforced by
gc_ratchet.py, needs a real profiling run to regenerate) and
test.yml's/driver.rs's floating +nightly for the Tier-3 auto-rebuild
feature (must track whatever nightly the end user has installed, not
this repo's CI-only pin).