QGA: define quickchr-scoped centrs handoff

[mobileskyfi]

Decision

Define how quickchr should support centrs using QGA for a quickchr-managed VM without making QGA a general RouterOS device transport and without adding a centrs passthrough mode to quickchr exec.

This follows the decision from #39: quickchr owns VM/QEMU channels; centrs owns validation, envelopes, target resolution, and protocol selection.

Strawman

• quickchr remains the QGA owner: QEMU channel setup, arch/KVM guards, raw qga() helpers, and ChrInstance.exec(cmd, { via: "qga" }).
• centrs may use QGA only after resolving a target with --quickchr <name> via quickchr's public API. It should not read machine.json or QGA socket paths directly.
• QGA is explicit-only in centrs. It is never auto-selected and should error if requested without a quickchr target.
• centrs still validates before run. A plausible validation path is QGA-executed :put [:parse ...], similar to centrs' console transports. If this is not CHR-proven on Linux/KVM, leave QGA unsupported until grounded.
• quickchr keeps quickchr exec as a raw/simple channel. No --via-centrs, no implicit validation dependency.

Open questions

• Should centrs expose the spelling as --via qga gated by --quickchr, or a namespaced --via quickchr-qga so it cannot be mistaken for a general device protocol?
• Does quickchr need descriptor/capability metadata so centrs can report QGA availability before attempting the call? See the descriptor handoff follow-up.
• What is the right mapping from quickchr QuickCHRError codes (QGA_UNSUPPORTED, QGA_TIMEOUT, etc.) into centrs transport/* or routeros/* errors?

Done-when

The direction is recorded, any quickchr-side descriptor/capability changes needed for centrs are filed or implemented, and the centrs side has a separate CHR-backed task before exposing QGA as a supported --quickchr path.

[mobileskyfi]

Centrs-side review result: keep this separate from the first centrs --quickchr slice.

My preference is a namespaced centrs spelling such as --via quickchr-qga, rather than bare --via qga, even if the implementation is gated behind --quickchr. Bare qga looks like a general RouterOS transport and could leak into CDB/default protocol settings later. A namespaced spelling makes the boundary obvious: QGA is a quickchr-owned VM channel, not a general device protocol.

Contract-wise, #71 should expose QGA only as optional capability metadata. Centrs should never read QGA socket paths or machine.json; if QGA is unavailable, quickchr returns the quickchr error and centrs maps it into a typed transport/target error. It should also stay explicit-only and never enter auto protocol selection.