fix(bazel): refresh MODULE.bazel.lock for path-absolutize

[0xzoz]

Summary

CI has been red on every Cargo-touching PR since 2026-08-03. This is the fix: two missing entries in MODULE.bazel.lock.

path-absolutize (and its path-dedot dependency) entered the workspace through codex-rs/execpolicy-legacy/Cargo.toml in 91f1f78 "release: prepare PFTerminal 0.1.27" without the accompanying lockfile refresh. The rules_rs crate extension records per-crate facts in MODULE.bazel.lock, so a dependency that never made it into the lock puts the extension permanently out of date:

ERROR: MODULE.bazel.lock is no longer up-to-date because the extension
'@@rules_rs+//rs:extensions.bzl%crate' has changed its facts

Because that check runs before anything is built, it takes down Bazel test on every platform regardless of what the PR touched. It is easy to misread as being caused by the PR under review — the error dumps the entire ~101k-crate fact set, which looks alarming and names none of the actual culprits.

Confirmed not specific to any one PR: #78 (adds a binary target) and #47 (a dependabot version bump) fail the identical set of checks.

What changed

Regenerated with just bazel-lock-update, exactly as AGENTS.md prescribes. The diff is the two missing crate entries and nothing else:

+ "path-absolutize_3.1.1": ...
+ "path-dedot_3.1.1": ...

Testing

./scripts/check-module-bazel-lock.sh — the same script CI runs — passes on this branch (exit 0). It fails on main.

Two pre-existing warnings are unchanged by this PR and left alone deliberately: platforms@1.0.0 resolving to 1.1.0 and rules_cc@0.2.18 resolving to 0.2.20.

Note on the remaining red

This unblocks the Bazel jobs. It does not fix repo-checks / build-test, which is a separate pre-existing failure — the manifest verifier flags code-mode-runtime, code-mode, and utils/home-dir for workspace crate features. Those need an owner decision about whether to drop the features or extend MANIFEST_FEATURE_EXCEPTIONS, so I have not touched them here.

[0xzoz]

Follow-up: #80 fixes the two CI problems this PR exposes.

Clearing the MODULE.bazel.lock gate here lets the Linux Bazel jobs actually build, which surfaced that they cannot finish in timeout-minutes: 30 on a fork PR (no BUILDBUDDY_API_KEY, so V8/ICU compile locally on a 4-core runner — cancelled at 30:18, 16,428/22,716 actions, 2/365 tests). It also surfaced that the cache-save step is gated on !cancelled(), so a timed-out job never saves the cache that would have made the next run faster.

#80 raises those timeouts, ungates the cache save, and removes the Windows/macOS jobs pinned to runners this repo cannot assign — the ones docs/ci.md already declares disabled.

Suggested order: this PR first, then #80.