Auto-bump @openfn/cli and @openfn/ws-worker via Dependabot

[elias-ba]

Description

Three orthogonal hygiene fixes around the @openfn/cli and @openfn/ws-worker runtime pins:

1. Fix .github/dependabot.yml. The existing /assets entry was set to ecosystem: "mix", which silently matched nothing. Change it to "npm" and scope it to @openfn/* so Dependabot opens a daily auto-PR when either package ships a release.
2. Move the @openfn/cli pin into assets/package.json. The version was previously a hardcoded Elixir constant (@cli_version in lib/mix/tasks/install_runtime.ex), which Dependabot can't track. The Mix task now reads the pin at compile time from package.json via File.read! + Jason.decode!, with @external_resource so recompiles trip when the JSON changes. Single source of truth for both pins.
3. Loosen brittle version assertions in web_and_worker_test. The test pinned exact builds for language-http, worker, node.js, and language-common. Each upstream release turned the test red for reasons unrelated to Lightning. Asserts each version key is present and looks like a version (\d+\.\d+) instead.

Pairs with #4760 (which removes the per-PR runtime checks entirely). These three changes stand on their own — they pay off whether or not those checks ever return.

Validation steps

• Run mix lightning.install_runtime after changing @openfn/cli in assets/package.json and confirm the new version is installed under priv/openfn.
• After merge, Dependabot will open its first bump PR within 24 hours of the next @openfn/* release.

Additional notes for the reviewer

AI Usage

• 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

[github-actions]

Security Review ✅

• S0 (project scoping): N/A, no changes touch project-scoped queries or web entrypoints — diff is limited to .github/dependabot.yml, assets/package.json, a Mix install task, and a test file.
• S1 (authorization): N/A, no new controller actions, LiveView events, or Bodyguard policy changes.
• S2 (audit trail): N/A, no writes to project or instance configuration resources; lib/mix/tasks/install_runtime.ex:14-25 only reads package.json at compile time.

[josephjclark]

Thank you for raising this @elias-ba ! The dependabot update is cool.

Looking at this stuff makes me want to rethink install_runtime and Lightning's relationship to the CLI.

I think this script is a hangover from long ago, before we had the worker, when the CLI was the runtime engine that executed jobs.

I think that Lightning's only dependencies on the CLI now are:

1. Integration tests
2. Metadata loading

The fact is that this quite complex install_runtime script is just installing 2 npm packages (and I'm not even sure what common is used for).

The script is also installing the CLI globally, which I don't think I love.

This is all too big to address here, but I'm feeling a compulsion to do something

[josephjclark]

hmm. I liked this at first, but these are dependencies of the app frontend. The CLI isn't a dependency of that at all. So I'm not sure this is the right place.

And actually, given that lightning depends on the CLI in production, shouldn't it be a prod dependency?

[josephjclark]

Oh wait - also, install_runtime will install the CLI globally. But npm install --prefix assets will install a local CLI in this folder. I'm not actually sure which bin will get used when running openfn (probably the global one).