fix: declare what each watchdog budget is anchored on, and stop arming guesses

[ppat]

Superseded by #884 — closed unmerged

This PR's central mechanism was overruled by the operator before it landed, and #884 replaces the
construction it was built on. Nothing here should be revived as-is.

What this PR did: declared a BUDGET_BASIS per role (measured / adversary / guess),
published it as basis= in event=budget, derived UNKNOWN_ROLES from it rather than a
hand-maintained list, and disarmed guess-anchored roles (tsserver, extensionHelper) under
enforce on the reasoning that killing on an underived number is worse than not killing.

Why it is superseded:

1. The disarming was overruled. The operator's decision is that every role is armed under
   enforce — things that exceed their share get killed. A mechanism that declines to enforce
   where it is least sure is inert exactly where it matters.
2. BUDGET_BASIS loses its meaning under feat: give the VS Code tree one memory envelope and shares of it #884. Budgets are no longer per-role numbers with
   independent provenance; each role holds a named share of a fixed 2048 MiB envelope for the VS
   Code tree. A share is allocated. It is neither measured nor guessed, so the taxonomy has
   nothing to classify.
3. RESTING_ROLE is deleted by feat: give the VS Code tree one memory envelope and shares of it #884. The resting x 1.5 floor is gone, so this PR's
   correction of the fileWatcher resting reference (88 -> 107 MiB) has no surface left to apply
   to. feat: give the VS Code tree one memory envelope and shares of it #884 carries the 107 MiB measurement forward as an input to its apportionment instead.

Salvaged into #884, with attribution: the BUDGET_ORDER determinism work (orthogonal to the
construction and worth keeping); the observation that tsserver launches with
--max-old-space-size=3072, re-verified live; and the 107 MiB fileWatcher measurement.

Findings recorded here that outlived the PR, because they are the reasoning behind #884's
shape and are not restated in full there:

• The old construction max(min(role budget, memory.max / 8), resting x 1.5) was asymmetric.
  The resting term is a floor, so a budget could never ship below a role's measured resting size —
  the failure this design shipped twice, most memorably an RLIMIT_DATA ceiling below what an idle
  file watcher already held. Nothing bounded a budget from above, so a number derived from
  measurement and a round number reached for in its absence sat in the same column and were
  enforced identically. Three of the four roles with no resting entry carried exactly 512 MiB.
• A ceiling derived from this dataset would be a worse instrument than a conservative guess.
  The sample is one operator, one Terraform/YAML repository, one 38-hour window whose first ~9
  hours had no VS Code tree connected. Across the managed population that window contains eight
  distinct processes — 1720 rows for a role is one process sampled 1720 times, not 1720
  observations. A ceiling fitted to that would put a healthy gopls, Pyright or rust-analyzer
  under a limit set by a language server that was never running.
• tsserver is launched with --max-old-space-size=3072 (observed live on both instances;
  VS Code's shipped default, set nowhere in the workspace's settings). Its 768 MiB budget was a
  quarter of the heap its own launcher sanctioned, while it was armed by default. This is now
  addressed at source in ppat/dotfiles#789, which caps it at 768 MiB via js/ts.tsserver.maxMemory
  — and which found that TypeScript spawns two tsserver processes that read the setting
  independently, so the previous 2048 MiB value sanctioned up to 4096 MiB for tsserver alone.
• A test description asserted the property its own assertion was meant to demonstrate, about a role
  that lacks it (extensionHelper "has a measured resting size" — it never had one). Fixed in feat: give the VS Code tree one memory envelope and shares of it #884.