examples: show centrs consuming a quickchr machine

[mobileskyfi]

Context

A runnable example should show the intended project boundary: quickchr creates/provisions the CHR and owns the VM lifecycle; centrs then uses the quickchr target to perform validated RouterOS operations.

This is separate from the lightweight help/setup/docs discovery issue (#72) because it depends on the centrs --quickchr surface from tikoci/centrs#134.

Strawman

Add either a new examples/centrs/ example or extend examples/harness/ with a centrs-specific sibling:

• boot or start a named quickchr machine;
• run a centrs command such as centrs retrieve --quickchr <name> /system/resource and centrs execute --quickchr <name> -- :put [/system/identity/get name];
• demonstrate that consumer code never reads machine.json; it goes through the public quickchr handoff / centrs --quickchr path;
• show the “after create/provisioning, use centrs for validated RouterOS work” workflow;
• clean up the machine in finally / existing example helper style.

Verification shape

Because this example depends on an external package and centrs#134, decide whether the quickchr smoke harness should:

• skip when centrs is not installed;
• gate only in an extended examples job; or
• use a repo-adjacent centrs checkout/package during local development.

Do not add a flaky example to the normal quickchr smoke set before the dependency shape is settled.

Dependencies

• tikoci/centrs#134 for --quickchr <name> target resolution.
• API: live descriptor contract for centrs --quickchr targets #71 if the example needs descriptor capability/version or SSH key metadata.

Done-when

The example is runnable, documented in examples coverage, and verifies the intended quickchr→centrs workflow without direct state-file reads.

[mobileskyfi]

Centrs-side boundary for the example:

Keep the first example to core RouterOS operations over the public quickchr descriptor: start/get a named machine, then run centrs retrieve --quickchr <name> /system/resource and centrs execute --quickchr <name> -- :put [/system/identity/get name].

Do not include btest in this example. That would push quickchr toward feature-specific provisioning or custom service setup, while quickchr should stay focused on CHR lifecycle and core system setup. If quickchr later exposes generic custom forwards in #71, centrs can decide separately whether btest should consume them, but it should not be a prerequisite for this handoff example.

[mobileskyfi]

Update from the centrs-side scope in tikoci/centrs#134:

The centrs --quickchr resolver issue now explicitly covers retrieve, execute, api, and transfer (with btest excluded). This quickchr example can still start with retrieve/execute for a minimal handoff, but once #134 lands it is reasonable to add a second step or variant that exercises centrs transfer --quickchr <name> list and a safe centrs api --quickchr <name> ... read.

Keep the example on public descriptor consumption only, and keep btest out of scope.