Epic: no code_saturne knowledge outside its adapter

[florian-simvia]

The principle

csauto was written for code_saturne, then opened to other solvers through the
SolverAdapter boundary. The boundary is real for the run lifecycle, but a
large amount of code_saturne knowledge still lives in modules with generic
names, outside csauto/solvers/.

The goal of this umbrella issue is a single, checkable property:

No code_saturne convention (file name, directory layout, log marker, regex)
appears outside csauto/solvers/code_saturne.py, except for a short,
explicitly documented list of accepted residue.

Moving those modules under solvers/code_saturne/ would not achieve it: a third
solver would then have to reimplement the machinery when all it needs is to
declare its own strings. The rule is generic mechanism, solver-declared
vocabulary — the split anomaly_file_names already demonstrates today.

Inventory

Five different shapes of fix, which is why this is split into children rather
than attempted as one change:

Site	What leaks	Shape
logs.py	outcome / anomaly / progress / restart regexes, RESU layout, performance.log parsing	A. adapter-declared patterns
probes.py, residuals.py	RESU/monitoring, RESU/profiles, residuals.csv	B. adapter-declared file layout
template.py	find_setup_file, find_run_cfg	C. plain move: already protocol methods, the adapter merely delegates
fastapi_routes/case_data.py, web_support.py	listing, monitoring, a hardcoded file list	D. plain wiring to anomaly_file_names, which already exists
execution.py, config.py, cli.py, runner.py	saturne_bin, --saturne-bin, TOML keys	E. accepted residue: allowlist it, change no code

C and D need no new mechanism and are short. A is the largest. E is not work at
all, only bookkeeping.

Why the boundary test does not catch any of this

tests/unit/test_solver_boundary.py scans 6 modules out of 20 for 5 tokens. It
is green today while cli.py contains 10 code_saturne literals and
fastapi_routes/case_data.py declares file: str = "listing" and
scope: str = "monitoring" as API defaults. Widening it before the work above
lands would produce roughly 160 hits and be unusable, so it is the closing
step, not the opening one.

Children

• #A logs.py: generic log engine + solver-declared patterns
• #B probes.py and residuals.py: adapter-declared results layout
• #C template.py: move find_setup_file / find_run_cfg into the adapter
• #D Wire case_data.py and web_support.py to anomaly_file_names
• #E Widen test_solver_boundary.py with an explicit residue allowlist

Suggested order: D, C, B, A, E. D and C are quick wins that reduce the
inventory before the large one; E closes the door once there is nothing left to
report.

Definition of done

• A new solver can be added by writing one adapter class, with no edit to any
  module outside csauto/solvers/.
• test_solver_boundary.py scans every generic module, with a documented
  allowlist for the residue in shape E.
• docs/architecture.md and docs/adding-a-solver.md describe the
  mechanism/vocabulary split rather than the current "all solver knowledge is
  behind the adapter", which is not true today.

Non-goals

• Changing the HTTP API shapes or the TOML keys. Already recorded as deliberate
  residue in docs/architecture.md.
• Any behaviour change for code_saturne users. Every child should be a pure
  refactor, verifiable by the existing test suite plus the golden values each
  child adds.