Collapse `other`'s per-file reference scoping into `plot_assembly`

[AlexisJanin]

Follow-up to #83, deliberately deferred out of it. Blocked by #83 — the registry seam has to exist first.

The smell

OtherDataSource knows what a spectrogram is.

other/find_load_format.py:114-118 holds PER_FILE_DERIVED_SECTIONS, mapping each derived-plot section key to a function that walks that section's config shape and prefixes every signal reference with <stem>::. That is a datasource carrying knowledge of the plot types — a layering inversion. It is also the site of the original PSD bug: the row was forgotten, so a per-file psd section validated cleanly and rendered nothing.

other does that scoping not because it understands plot types, but because it is the only thing that knows which files exist. Those two facts are separable.

The shape of the fix

ADR-0013 already established the rule one level up: config scope is desugared once — a per-datasource section is a namespace, and plot_assembly rewrites its references as qualified global ones at the head of assembly. other::<stem> is the same rule one level down: the file stem is a namespace inside the other datasource.

So other would inject its derived sections unqualified, keyed by stem, and plot_assembly would desugar them alongside the datasource-scoped ones it already handles.

Why it is worth doing

• Deletes a call site rather than cleaning it — after Extract a plot_types/ package — one module per plot type #83, other/find_load_format.py stops importing plot_types at all.
• With other no longer needing a plot type's config shape, the import-reachability constraint that forced Extract a plot_types/ package — one module per plot type #83's two-file split relaxes. schema.py and plot.py could then merge per type — cheaply, because the registry seam is already in place.
• One fewer place for the "validates cleanly, renders nothing" failure to hide.

Why it was deferred out of #83

#83 is already XL. Folding this in would make it also relitigate an ADR that landed days earlier (#89 / ADR-0013), and if the desugaring merge turned out to be wrong it would be discovered buried inside a ~900-line refactor rather than in its own diff.

Acceptance sketch

• other/find_load_format.py no longer maps section keys to qualifier functions, and imports nothing from plot_types.
• Per-file other::<stem> derived sections are desugared in plot_assembly, by the same code path as per-datasource ones.
• Both config spellings stay valid — no parser change, no config migration (as in Lift PlotGroup assembly out of wrapper.main into plot_assembly.py #89).
• Snapshot tests unchanged.
• Evaluate whether schema.py / plot.py should then merge per type; if so, do it here or open a third follow-up.

Relations

Follow-up to #83. Same area as #89 / ADR-0013.

[AlexisJanin]

The last checkbox, answered

Delivered in #93. The first four acceptance criteria are met as written — other/find_load_format.py maps no section keys and imports nothing from plot_types, per-file other::<stem> sections desugar through the same plot_assembly path as per-datasource ones, both config spellings stay valid, and snapshots are unchanged.

The fifth — "evaluate whether schema.py / plot.py should then merge per type" — is no, but not for the reason #93 first gave.

The PR originally answered "no, the split is load-bearing" on the strength of a simulated merge that raised ImportError in loop/plot.py. That result came from a tree modified to settle the datasource cycle first; the same measurement also recorded that both designs import fine through the normal entry point. Re-run against the tree as it stands, a registry importing all three plot.py modules at module scope breaks nothing.

That constraint has since been removed outright — signal_container no longer imports the registry at all, so the cycle is not merely dormant, it is off the graph. Which means this issue's own prediction was right: "the import-reachability constraint that forced #83's two-file split relaxes."

The split was still kept, on the grounds the issue itself supplied. #83 chose the layout because it "mirrors datasource/sources/<name>/ exactly", and that parallel is now the whole argument: a declarative half and a working half, as options.py and find_load_format.py are. Concretely, psd is 302 lines of spreadsheet row accumulation and group resolution against 154 lines of a Welch call — the person asking why a row did not become a plot is not the person asking why a PSD is scaled wrong.

What did merge is registry.py and builders.py, split for the same now-dead reason. Registering a plot type is two adjacent lines in one file.

schema.py was renamed definition.py in the same pass — it holds identity and capability flags as well as config grammar, and "schema" was already taken twice elsewhere in the codebase.

No third follow-up needed for this. Four unrelated maintainability items from the last review are listed under Known, deliberately left in #93 and can have their own issue if worth it.