Install v2 GitHub actions for v2 sync connections

[midigofrank]

Description

This PR makes v2 GitHub sync connections use @v2 of the OpenFn deploy and pull GitHub Actions. These actions sync an openfn.yaml CLI workspace with openfn project pull and openfn project deploy. Legacy connections stay on @v1 and behave as before.

Stacked on sandbox-sync-ui.

Installing the actions

• New templates, priv/github/deploy_v2.yml and priv/github/pull_v2.yml, are picked when sync_version is true.
• Deploy only runs on pushes that touch the project's workspace folder or its own workflow file. It can also be dispatched by hand with force, and a commit with [openfn force] in its message forces a deploy. The v2 "Configure OpenFn" commit uses this marker.
• Pull and deploy share a concurrency group per branch, so they never push to the same branch at once.
• The pull run name includes the project id. openfn-pull.yml is shared by every project in the repo, and the id is how Lightning finds this project's runs.
• The API secret is now written before the deploy workflow is pushed, because the workflow can run as soon as it lands on the branch.
• For v2, Lightning no longer commits a config file. Verifying the connection no longer checks for one, and disconnecting leaves openfn.yaml in place.

Workspace folder and local alias

• New workspace_path column on project_repo_connections sets where the CLI workspace lives in the repo (default .). It can be changed on reconnect, and the change is audited as repo_connection_updated.
• New virtual local_alias is passed to the first pull. The CLI uses it to name the project's local copy.
• config_path and workspace_path are validated as plain relative paths inside the repo because they get written into the workflow files. The alias is validated because it ends up in a filename.
• The config format, workspace folder and local alias fields sit in a collapsed "Advanced settings" section.
• Before connecting, the form checks the chosen branch and workspace (VersionControl.check_workspace/2):
  • If another local project already uses the alias, the Connect button stays disabled until a different alias or folder is picked. The CLI won't pull while the alias clashes. The warning links to Advanced settings.
  • If another project already syncs to the folder, the form warns, and the confirm box says that project's files will be replaced. Deploying (importing) from another project's folder is the normal case and gets no warning.
  • If the repo's shared openfn-pull.yml uses the other format (v1 vs v2), the confirm box warns that connecting replaces it and stops syncs for the projects already using it.

Sync status (connected v2 connections)

• VersionControl.get_sync_status/1 reads the branch's .openfn/branches/<branch>/checkout.yaml and .projects/*.yaml to tell whether the branch tracks this project. It also fetches the latest pull and deploy runs (new GithubClient.list_workflow_runs/4). A workflow GitHub doesn't list yet (a 404, e.g. not yet run and not on the default branch) counts as having no runs.
• The "verify connection" banner is replaced by a sync health block with one row each for repository setup, branch tracking, last pull and last deploy. It has a manual refresh and polls while the first sync is setting up.
• The connected panel shows the workspace folder and the project's local alias.

Validation steps

1. Point VersionControl.endpoint_url/0 at a public URL (e.g. ngrok) so the actions can reach your local Lightning.
2. In project settings → Sync, connect a repo with the v2 format. Optionally set a workspace folder and local alias under "Advanced settings". Try a folder another project already uses to see the alias clash and takeover warnings. Try both directions.
3. Check that openfn-pull.yml and openfn-<project>-deploy.yml land in the repo, no config file is committed, and the first sync run commits the workspace.
4. Back on the Sync tab, the status block should go from "Setting up" to "Sync healthy" and show the last pull/deploy runs.
5. Change a workflow in the workspace on the branch and push. Deploy should run. Pushing outside the workspace folder should not trigger it.
6. Reconnect with a different workspace folder and check the audit trail. Disconnect and confirm openfn.yaml is left in place.
7. Connect a legacy-format project and confirm nothing changed.

Additional notes for the reviewer

1. Do not merge as is: the v2 templates point at midigofrank/cli-deploy-action@v2 and midigofrank/cli-pull-action@v2 for testing (df7f500). They need to go back to the OpenFn actions once those @v2 tags are published.
2. workspace_projects/2 makes one GitHub request per local project copy. That's fine for the few copies a workspace holds, and it's marked with a ponytail: comment.
3. The status checks rely on the CLI's file layout (checkout.yaml, .projects/<alias>@<host>.yaml), taken from the @openfn/project and @openfn/cli sources. If the CLI changes that layout, the checks break.

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

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer)
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[josephjclark]

Can we rename this to Deploy changes to OpenFn

[josephjclark]

And rename this to Pull changes from OpenFn

[josephjclark]

This will need to be saved under openfn - is this just becuase you've built a test action in your own repo?

[midigofrank]

Yeah, this is just for testing. I'm going to revert it

[github-actions]

Security Review ⚠️

Other Security Observations

• priv/github/deploy_v2.yml:31 and priv/github/pull_v2.yml:46 — the v2 workflow templates installed into every connected user's repo reference midigofrank/cli-deploy-action@v2 and midigofrank/cli-pull-action@v2, a personal GitHub namespace rather than the openfn organization the CHANGELOG advertises. These actions run with contents: write and the project's OpenFn API key (${{ secrets[inputs.apiSecretName] }} / secrets.<api_secret_name>), so if that personal account is compromised or force-pushes the v2 tag, every v2-sync customer executes attacker-controlled code with their OpenFn API token. Commit df7f500fc5 ("Point v2 GitHub actions at midigofrank forks for testing") suggests this is temporary, but nothing on the branch reverts it before merge.

S0, S1 and S2 pass: new web-layer events (save, reconnect, delete-connection, initiate-sync) still gate on can_install_github / can_initiate_github_sync and derive project_id from socket.assigns.project rather than params (lib/lightning_web/live/project_live/github_sync_component.ex:46,57,88,99); check_workspace/2 guards via authorize_installation_access (lib/lightning/version_control/version_control.ex:219); get_sync_status/1 operates on the connection loaded by the parent LV with get_repo_connection_for_project(project.id); workspace_path is persisted and audited via a new repo_connection_updated event inside the same Repo.transact (lib/lightning/version_control/version_control.ex:87,104, lib/lightning/version_control/audit.ex:60); and workspace_path / local_alias are format-validated and rejected on absolute paths or .. traversal (lib/lightning/version_control/project_repo_connection.ex:93-108,135-139).