lint: addr_class_inventory fails on main — 2 real ratchet regressions plus a stale allowlist substring #7259

Step 7 of the lint job, scripts/addr_class_inventory.py, exits 1 on main (cdb3934). It is currently masked: the job stops at step 3 (#7257), so this has not been visible in CI.

Confirmed unrelated to #7256 (the file-size split) — that PR's finding set is byte-identical to main's.

There are two independent problems.

1. Two genuine ratchet regressions

  [handle-floor] crates/perry-runtime/src/child_process/value_util.rs: 3 site(s), baseline allows 1
      line 103: if ptr.is_null() || (ptr as usize) < 0x1000 {
      line 222: if opts_ptr > 0x10000 {
      line 225: if args_ptr <= 0x10000 {
  [handle-floor] crates/perry-runtime/src/fs/dirent.rs: 3 site(s), baseline allows 2
      line 132: if raw_ptr < 0x1000 {
      line 184: if raw_ptr < 0x1000 {
      line 217: if refreshed_ptr < 0x1000 {

Three new hand-rolled address floors landed without going through
crates/perry-runtime/src/value/addr_class.rs. Per the gate's own rationale these should use is_handle_band / is_above_handle_band / try_read_gc_header: a bare < 0x1000 floor does not reject the fetch/zlib/proxy handle bands, and dereferencing a handle segfaults on Linux while macOS hides it (#1843, #4004, #4665, #4800, #6271).

This is a real correctness fix, not bookkeeping — it should not be silently ratcheted up.

2. A stale allowlist entry that no longer matches its code

  crates/perry-runtime/src/object/native_module/constants.rs: [band-literal] ("O_SYMLINK", (0x200000) as f64),

scripts/addr_class_allowlist.txt has an entry keyed on both a path prefix and a line substring:

crates/perry-runtime/src/object/native_module/constants.rs | "O_SYMLINK" => Some(0x200000), | fs.constants O_SYMLINK flag value; unrelated to the handle bands (split of native_module.rs)

constants.rs contains O_SYMLINK in two syntaxes, and the entry only matches one of them:

• "O_SYMLINK" => Some(0x200000), — matches, suppressed
• ("O_SYMLINK", (0x200000) as f64), — does not match, so it fails the gate

Both are the POSIX O_SYMLINK fcntl flag value, unrelated to the handle bands. The fix is a second allowlist entry (or widening the substring to O_SYMLINK).

Related: pre-existing baseline staleness (warning-only)

check_ratchet also reports stale entries — counts that dropped without the baseline being lowered. These do not fail the run (they are printed after the return 1), but they are drift:

• handle-floor | crates/perry-runtime/src/node_submodules/test.rs: baseline 2, actual 1
• handle-floor | crates/perry-runtime/src/process/env_misc.rs: baseline 3, actual 1

Two whole-file allowlist entries also appear to suppress nothing any more and could be dropped (verified by running the inventory with and without them and diffing the output):

• crates/perry-runtime/src/array/generic.rs | *
• crates/perry-runtime/src/node_submodules/test.rs | *

Design note worth considering

Both the ratchet baseline and the whole-file allowlist entries are path-keyed. That makes any file split a potential gate failure even when no code changed: a ratcheted site moving to a new sibling gets baseline 0 (hard fail), and allowlisted code moving out of an allowlisted path loses its suppression. #7256 hit both and had to re-pick seams to keep specific functions in their original files. If file splits are expected to continue (#1435), it may be worth keying suppressions on something more stable than the path.