feat: native dock pinning and login items (CLI side)

[fullstackjam]

What does this PR do?

Promotes Dock pinning and Login Items from post_install shell blobs to first-class snapshot capture + declarative install fields on the CLI side.

Why?

Today users pin Dock apps and register Login Items by hand-writing defaults write com.apple.dock persistent-apps -array-add '<plist xml>' and osascript tell application "System Events" blocks inside the `post_install` array — both are common-enough macOS setup actions that they deserve first-class treatment alongside Homebrew packages and defaults preferences.

After this PR:

• openboot snapshot automatically captures dock_apps (list of app paths) and login_items (list of {name, path, hidden}) from the live system.
• openboot install from a RemoteConfig applies them declaratively (wipe-and-rebuild — install completes with the Dock / Login Items list matching the config exactly).
• post_install is unchanged; users may keep existing scripts or migrate to the new fields.

Spec: `docs/superpowers/specs/2026-06-07-dock-and-login-items-design.md` (local, gitignored).
Plan: `docs/superpowers/plans/2026-06-07-dock-and-login-items-cli.md` (local, gitignored).

Testing

• go vet ./... passes
• L1 (`make test-unit`) green, including archtest baselines
• Unit tests added: 5 Dock parser + 5 login-items parser + 1 Dock -blob regression guard + dry-run command-sequence assertions for SetDockApps / SetLoginItems + installer subtask integration tests
• Manual smoke on real machine: openboot snapshot --json | jq '{dock_apps, login_items}' returns the live Dock and Login Items correctly

Cross-repo checklist

• Does this need a docs/content update in openboot.dev? — Yes, follow-up PR. The server-side schema (RemoteConfig TS type + dashboard list editors + inline install-script generator) is intentionally scoped out — this PR only ships the CLI side so users can snapshot/install from local JSON files immediately. Plan 2 covers the web side.
• Does this change the CLI ↔ server API contract? — Additively yes (two new optional fields on RemoteConfig). openboot-contract schema update should land alongside the web work. Old CLIs ignore unknown fields; new CLI treats missing fields as "skip subtask", so wire compatibility is preserved.

Notes for reviewer

Known limitations (intentional, out of scope):

1. `PlanFromSnapshot` (the openboot install --import snap.json path) doesn't carry dock/login items yet — needs SnapshotDockApps/SnapshotLoginItems on config.InstallState. RemoteConfig install path works fully.
2. Three `LoginItem` types coexist (snapshot/config/macos) due to unavoidable import-cycle constraints; mapping happens at `installer/plan.go`. Could be unified later by moving to an internal/types package.
3. macos/dock.go and macos/loginitems.go use raw fmt.Print* for dry-run output (baselined in fmtprint.txt) because the macos package can't import ui (cycle via snapshot). Follows existing precedent — macos.go already had 3 such baselined lines.

Real bug found during verification: initial implementation used `plutil -extract persistent-apps json` which fails on real Dock plists because `tile-data` contains `` blobs (alias bookmarks, icon thumbnails). Switched to `xml1` + stdlib encoding/xml token walker. Regression test `TestParseDockAppsXML_DataBlobRegression` guards against silent reintroduction.

Archtest baseline changes:

• `fmtprint.txt`: +8 lines for new files in `internal/macos/` (import-cycle workaround)
• `dryrun.txt` exempt list: +2 entries for `internal/snapshot/dock.go` and `internal/snapshot/loginitems.go` (read-only system probes, same rationale as already-exempted `capture.go`)
• `no-direct-exec.txt`: line-number drift only (pre-existing `exec.Command` in `applyPostInstall` shifted because `applyMacOSPrefs` was restructured)

🤖 Generated with Claude Code