Owner-side GuardedStack reclamation of External user-stack frames (#470 residual leaf leak)

[ryanbreen]

Background

PR #470 PR-2 (fix/470-pr2-leaves) marks borrowed user-stack frames as
External (never decref'd through the normal owned-frame path) in order to
eliminate main's live over-free of kernel-HHDM-live stack frames — the
#470/#528 corruption class — per DESIGN-470-v2 §1.6 (2-layer design: allocator
frame ledger + custody records).

Residual: benign per-exit leak

The safe residual of that design is: External user-stack frames are not yet
reclaimed on process exit — GuardedStack::Drop is currently a no-op for frames
marked External. This is a deliberate, bounded, per-exit leak (never an
over-free/corruption) that trades safety for a small footprint cost, pending
owner-side reclamation.

Follow-up work: implement owner-side GuardedStack reclamation of External
user-stack frames — i.e. give the actual owner of a borrowed/external stack frame
(rather than the borrowing process that merely mapped it) a path to reclaim it once
it is truly no longer referenced, closing the residual leak left by the #470 F4
custody work.

Smaller note: leaf-lock granularity on the CoW fault path

acquire_leaf_mapping takes a blocking EXTERNAL_LEAF_SPANS Mutex on the CoW
fault path (a leaf lock scanning <=16 entries — this replaced/net-removed main's
prior global FRAME_METADATA lock on that path, which is a net improvement). As a
smaller hardening item: prefer try_lock() over a blocking lock in fault handlers,
consistent with the kernel's general rule that fault/interrupt-path code should not
take blocking locks (see CLAUDE.md interrupt/syscall hot-path rules).

Related

Follow-up to #470 (aarch64 leaf-frame custody, closed via PR-1a/PR-1b/PR-1c and this
PR-2/F4 exec-path-leaves work). Links #480.