feat(converge): spec.manage describe-only protects adopted members (#325)

[ChrisonSimtian]

Closes #325.

An adopted guest predates the shape describing it, so its live config will never fully match.
Converge couldn't tell that difference was intentional, so it reported the member as drift on
every run and every apply wanted to "fix" it.

spec:
  manage: describe-only     # converge may READ this member; never write it

Verb	Before	After
plan	DRIFT / SetConfig, every run	DESCRIBE-ONLY (adopted; documented, never written), own summary figure
apply	wrote to it	SKIPPED, counted as skipped
destroy	would destroy it	REFUSED

Naming a describe-only member in --only does not override any of it. Allowing that would put
the guarantee back in the operator's hands, which is exactly what this set out to stop.

Why this and not just --only

stacks/SmartHome/CLAUDE.md has always said VM 2000 is "never re-provisioned by converge --apply". That guarantee lived only in prose — nothing in the engine enforced it. #324 made it
avoidable, but opt-in safety on a destructive default is the wrong shape for something whose failure
mode is rewriting an irreplaceable hand-built HAOS install.

Verified live

The SmartHome plan that previously ended:

VM members (1) — via ProxmoxSharp:
▸ homeassistant  (vmid 2000, node hpe-01) — SetConfig

now reads:

▸ homeassistant  (vmid 2000, node hpe-01) — DESCRIBE-ONLY (adopted; documented, never written)

and --only homeassistant --apply → 0 applied, 0 no-change, 1 skipped, 0 failed.

Two honest notes

Destroy was never a risk for VM 2000. converge --destroy is CT-scoped and doesn't touch VM
members at all, so I found the REFUSED line didn't appear for it and corrected the shape comment
rather than leaving it implying a protection that wasn't in play. The marker does make destroy
refuse a describe-only LXC — that path is unit-tested.

Describe-only is not exclusion. The member is still loaded, still shown in plans, and still
resolvable as a dependsOn target — describing it is the point. Absent or managed behaves exactly
as before, so no existing shape changes behaviour.

Schema

manage added to both $defs.lxcSpec and $defs.vmSpec — each has
additionalProperties: false, so a shape using it would otherwise fail validation — plus the
matching model properties the SchemaDriftTests tripwire requires. Merging this refreshes the moving
schema-v1 release channel, which the stack repos validate against.

Tests

11 new (185 total). Marker parsing incl. case-insensitivity and the absent/managed defaults;
apply skips it and still handles its neighbour; --only can't override it; destroy refuses even with
--yes; plan labels it and keeps it out of the drift count.

One test — drift is still reported for managed members, guarding against the marker disabling
the drift machinery wholesale — failed on first write, because my fixtures declared no comparable
fields and so were proving nothing. StateDiffer only compares a field the shape actually claims.

Merge order

This first (it refreshes schema-v1), then Homelab.Stacks.SmartHome#8 which applies the marker
to VM 2000, then a pointer bump. The submodule's validate will fail against the currently pinned
schema until this lands.

Not applied to CT 4100

It looks like the other adopted member, but it's stopped and tagged retired — Mate runs on the
podman host now (podman-host/quadlets/leapmotor-mate.container). Its shape is dead weight pending
the CT's deletion, not an adopted member to protect, and marking it describe-only would assert
something false. It stays a (legitimate) drift entry, noted in the stack's CLAUDE.md.