maxmemory footprint correction: two uncorrected consumers left over from #475 (Linux swap; db-maxmemory)

[TinDang97]

Two secondary findings enumerated in #475's 2026-08-28 rescope comment survived the fix that closed that issue (#765 corrected the inline write path's pre-gate). Both reproduce on main @ f7c83769. Filing so they are not lost with #475.

Neither is covered by #867, which is about the macOS divisor growing as eviction proceeds.

1. The Linux footprint correction excludes swap

footprint_correction() derives its ratio from /proc/self/statm resident on Linux
(src/admin/footprint.rs:119). Resident excludes swapped-out anonymous pages.

$ grep -rn "VmSwap" src/
$                       # nothing

So on a bare-metal Linux host with swap enabled, the correction disengages precisely
during the swap event — the operator's process is being paged out, used_memory is
unchanged, resident is falling, and the ratio drops toward 1.0 exactly when it should be
rising. That is the same failure mode #475 was originally filed about, on the other OS.

Defensible for a cgroup-limited container (where swap is usually off and the memory
controller is the real bound). Wrong for a host with swap on, which is the default on most
distributions.

What would settle it: a Linux instance with swap enabled, maxmemory set,
load until VmSwap in /proc/self/status is non-zero, and INFO memory's
maxmemory_footprint_correction read at that point. If it sits at ~1.0 while VmSwap
is large, the finding is confirmed as filed.

2. db-maxmemory enforcement is an uncorrected consumer

src/storage/db_quota.rs compares raw db.estimated_memory() against the per-db limit:

// src/storage/db_quota.rs:235
let mut current = db.estimated_memory() as u64;
// :240, :253 — before/after, same raw quantity

There is no effective_budget(...) call and no footprint_correction() divide anywhere in
the file. db_quota.rs's own module doc says "Enforcement mirrors global maxmemory
exactly" — after #765 it no longer does. An operator who sets both --maxmemory and
--db-maxmemory now gets a footprint-corrected global cap and an uncorrected per-db one.

#475's rescope comment flagged this as "a second, smaller uncorrected consumer — being
evaluated for this PR vs a follow-up." It went to follow-up; this is the follow-up.

Smallest fix: route the per-db comparison through the same eviction::effective_budget
that #765 made the single implementation, and extend
test_inline_pre_gate_agrees_with_slow_path_under_footprint_correction's ratio sweep to
cover the db-quota gate — the pattern is already established, and the reason #475 shipped
at all was that no assertion used a ratio > 1.0.

Severity

Neither is a live-instance emergency. (1) is a correctness gap that only appears on a
swapping Linux host; (2) is scoped to instances that configure db-maxmemory at all.
Filing them at the same fidelity they were found, not inflating them.

Refs: #475, #765, #867, #510.