Group plugins into the fewest workers: planner from pins and running history, proven by the benchmark #182

The operator's priority (2026-10-27): take the most advantage of plugin-hostd's ability to run many plugins in ONE process, to save CPU and RAM, on Zynthian first and then everywhere the host runs.

What decides the grouping:

• Qualification: a pin's verdict says which plugins may share a worker (only in-process verdicts do), with their measured cost, memory and latency.
• Running history: what each plugin actually did on this machine (CPU, xruns, worker restarts, crashes), kept per plugin and per host class, so the host groups what has been steady together and keeps a plugin that misbehaved on its own.

What to build:

1. A grouping policy in plugin-hostd: given a chain (or a set of chains), pack the members into the fewest workers the pins and the history allow, and say why for each plugin left on its own. Same inputs give the same plan.
2. A running-history record, written by the host and read by the planner and by plugin-qualify (the qualification can use it to promote or demote a verdict).
3. Proof from the benchmark: the omx-bench/1 chains-vs-processes runs on the Pi 5 and the desk must show, at the same load, fewer processes, lower RSS/PSS and CPU, and no more xruns than one process per plugin; and under stress, fewer xruns with grouping than without. A grouping that does not win in the benchmark is not shipped as the default.
4. Zynthian: the PH engine builds its chains through the planner, so every Zynthian chain is grouped as far as the pins allow.