Read private plugin preferences from an optional local overlay

[mosobande]

Why

This repository is public, but some teams prefer a workflow plugin that lives in a private repository. Naming that plugin here exposes it. Its preference now lives in a file on the user's machine, and the public base lists only public plugins.

What changes

• steps/engine.py: load_yaml('plugins.yaml') merges ~/.agent-setup/overlay.yaml when it exists. Each overlay row's job must match a public row, and its other keys (today preferred) are merged in. An unknown job stops setup with its name. The existing preferred-plugin path is unchanged: the read-access check, the per-host install, optional packs, and the fallback to the public plugin.
• base/plugins.yaml: the private preferred block is removed. The row keeps the public qp-skills plugin.
• README, example and the instruction-ownership decision record now say "the workflow plugin". The README gains a short "Optional private overlay" section with a neutral example. Step 6 still runs the selected plugin's own setup skill.
• Tests use neutral fixtures (example-org/workflow). New tests cover: no overlay installs public rows only; an overlay adds preferred and drives the install and fallback path; an unknown job fails with its name.

Proof

• mise run check exits 0: ShellCheck; gitleaks (no leaks found); 52 unit tests OK.
• A case-insensitive git grep for the private plugin's name and its skill names prints nothing.

Rollout

Machines that should keep the private plugin need the overlay file before their next setup run. Without it they fall back to qp-skills; nothing is uninstalled. Merge this after the overlay is published on the private side.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}