More deploy stuff

[josephjclark]

Likely to be a bitty PR with numerous small changes:

• Allow --format state on fetch to download a v1 state file. Not well tested. Useful for debugging only. Should write to .projects if -o isn't set, but that's not tested either. Proabably I should undocument this flag

AI Usage

Please disclose how you've used AI in this work (it's cool, we just want to know!):

• Code generation (copilot but not intellisense)
• Learning or fact checking
• Strategy / design
• Optimisation / refactoring
• Translation / spellchecking / doc gen
• Other
• I have not used AI

You can read more details in our Responsible AI Policy

Release branch checklist

Delete this section if this is not a release PR.

If this IS a release branch:

• Run pnpm changeset version from root to bump versions
• Run pnpm install
• Commit the new version numbers
• Run pnpm changeset tag to generate tags
• Push tags git push --tags

Tags may need updating if commits come in after the tags are first generated.

[josephjclark]

Things I might look at here:

• a nice clear confirmation message, even in debug mode, before the confirm prompt. like a diff summary
• allow any v1 statefile or v2 project file to be deploy (by path)
• if projects have no history, that's probably a bug, so maybe skip divergence testing with a warning?
• Tests!!!

[josephjclark]

Think I've stumbled into a sizeable problem here. When loading the deploy project from the fs, there's no history. So you're always try to merge a zero-history workflow into one with a history. Which results in an error, because we can't guarantee no overwrite.

But when deplying, don't we merge the fs into the local target? So why doesn't the local-merged Workflow have the history from the local file? Maybe this s just a tiny bug in workflow merging

Is there also a problem here:

1. User fetches a workflow
2. User matches a change locally. New history.
3. User fetches from app. App has a new edit. So the local history (which excludes the current change) has an extra item.
4. Now the history locally is kinda wrong right? there's a mismatch between what's on the disk and where we forked from the remote

What we may need to do is: on fetch, if the local version is different to the new version coming down, we generate a new cli version in local history. Part of the problem there is that the version hashes aren't actually compatible.

Hmm. Getting a bit tricky in here...

If we track the version the local edit was forked from, like the source version, then we can work it out. But when do we record that?