Sync: split up openfn.yaml

[josephjclark]

Short Description

This PR splits openfn.yaml into two parts: workspace settings (including colllections and channels) still sit in openfn.yaml. But all local state stuff in the project keys is moved to a .openfn folder, which should be gitignored.

This should really help clean up github diffs. The stuff you don;t want to merge - like the checked out project uuid - can be untracked.

To make this work, the checkout code will recognise if you're using git, and will track state per branch. So you can switch branches or pull the project and it'll configure itself. This should be mostly invisible and seamless.

Some caveats:

• project.yaml files will still be target to merge down to the base branch, and will appear in the diff. users can manually delete before merging, or add githooks. We could consider adding gitattributes to make it look like a binary so at least it's hidden. But there's no way to both track the state AND ignore it in merge.

Still to do:

• Tests need updating and fixing
• Update the default project with the right config
• Update docs because the project structure has changed quite a bit
• Test very very thoroughly

AI Usage

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

• I have used Claude Code
• I have used another model
• 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]

Are we absolutely sure the .openfn folder works? Since it's not tracked, when a user does git clone, they'll pull the branch down but won't have any local state available. The CLI won't know which state file is checked out.

There's no other binding between the checkout an the project file. So you have to run opennf checkout with the correct alias to set yourself up.

It also means if you look at the branch on github, yes you can see its contents and any tracked state files. But you can't know which project/sandbox you're looking at. If the branch and and sandbox name agree you can infer it I suppose. But you sill want to run a checkout locally.

I don't think we're there yet.

[josephjclark]

Idea: maybe when you pull the branch from GH, and you get no state, and so the CLI doesn;t know what's checked out... but the CLI knows this! It could prompt the user "which project is tracked" and pick one from the list. That's all we need. It could even auto-infer from the branch name.

We just need that one hook to get started.

The only possible concern then is that the user doens't have forked_from references for other versions. Does that matter? Does that block merging or deploying? If forked from is articifically created fresh does that user lose anything?