feat(sync): persist prompt sync manifests

[ctawiah]

Context

The manifest is the local baseline used to determine which side changed since the last successful sync. This layer introduces only that persistence contract, before local prompt wrappers and mutation workflows are added.

What changes

• Defines manifest resources by project, resource kind, and lookup key.
• Records stable fingerprints for the last accepted state.
• Reads and writes deterministic YAML.
• Uses atomic replacement and validates duplicate resource identities.

Review focus

• Is the manifest deterministic and easy to review in Git?
• Are malformed or duplicate entries rejected clearly?
• Can an interrupted write leave the previous manifest intact?

Verification

• go test ./internal/sync/...
• git diff --check

Related changes

Review the stack in this order:

1. Sync foundations
2. Prompt reference workspaces
3. Prompt sync manifests
4. Local prompt workspaces
5. Bootstrap prompt workspaces
6. Link and detach prompt resources
7. Prompt reconciliation
8. Prompt sync orchestration
9. Prompt sync command

---

Note

Overview
Introduces internal/sync/manifest, a new persistence layer for the sync baseline: a versioned manifest.yaml under the repo’s sync root that records each tracked resource’s last accepted sha256: fingerprint keyed by resource kind, project, and lookup key.

The model adds helpers to upsert/remove entries, validate format version, fingerprints, duplicate identities, and unsafe path segments, and sort resources for stable Git diffs. The store loads missing files as an empty manifest, rejects unknown YAML fields and multi-document files, and writes via temp file + rename (with sync) so readers see either the old or new file. Tests cover round-trip determinism, validation edge cases, and atomic write behavior.

^{Reviewed by Cursor Bugbot for commit c07599b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 766f9bd. Configure here.}

[nieblara]

LGTM

Quick ux question: The manifest is committed, so each branch has its own baseline, but LaunchDarkly only has one state. Say someone archives or edits a prompt on a feature branch and syncs. Every other branch, main included, will then see delete_local / update_local for changes that were never merged, and with --yes those get applied automatically, right?

Is the intended workflow to only sync from the default branch? If it is, maybe add a warning when someone syncs from a different branch, or at least mention it in the help text.

[ctawiah]

LGTM

Quick ux question: The manifest is committed, so each branch has its own baseline, but LaunchDarkly only has one state. Say someone archives or edits a prompt on a feature branch and syncs. Every other branch, main included, will then see delete_local / update_local for changes that were never merged, and with --yes those get applied automatically, right?

Is the intended workflow to only sync from the default branch? If it is, maybe add a warning when someone syncs from a different branch, or at least mention it in the help text.

Good catch! Ideally, developers should be able to sync from any branch. I plan to move the manifest to LaunchDarkly instead locally in the source code and add version checks to fix concurrent updates, then I'll look into preventing stale branches from overwriting newer LaunchDarkly state - i've added a ticket to track this.