reconciler: cronix adopt for systemd-timer backend

[awbx]

Split off from #11. The crontab Adopter implementation shipped in v1.0.0-rc.x as the reference. Implement the same backends.Adopter interface for systemd-timer so cronix adopt --backend systemd-timer works.

What ships

• systemd-timer backend implements backends.Adopter (interface in go/internal/backends/backend.go).
• Detection heuristic: find an unmanaged entry that invokes cronix trigger <app>.<job> (the equivalent for this backend — e.g., on K8s, a CronJob whose container args end with trigger <app>.<job>).
• Divergence reporting: schedule, command tail, env, any other field that would change semantics under management.
• Idempotent: a second adopt run on an already-managed entry returns AlreadyManaged=true with no action.
• Dry-run honored: opts.DryRun=true must not modify the backend.

Acceptance criteria

• go test ./internal/backends/systemd-timer/... -run Adopt covers: single-schedule success, dry-run, divergent schedule, already-managed, no-candidate, multi-schedule all-present, partial multi-schedule divergence.
• Interface-compliance test: var _ backends.Adopter = (*Backend)(nil).
• Integration test against a real systemd-timer instance (CI matrix from ci: backend matrix (k3d, systemd-in-container, LocalStack) #10).
• Docs page operations/migrating-from-<backend>.md documenting the per-backend gotchas.

Reference

See go/internal/backends/crontab/adopt.go and its test file for the contract every backend's Adopt implementation should satisfy. The crontab implementation is intentionally strict (exact tail match, exact schedule match) to set a conservative bar; per-backend implementations can relax this only where the backend has cleaner equality semantics (e.g. K8s API resource comparison).