Adaptor Version Rethink

I think we should reconsider how adaptor versions work on the platform. This is related to #2843, which fixes an immediate problem, but this issue I hope is a longer term view.

The Problem

• Workflows tend to get locked on an old patch version and never get updated. This can introduce security concerns.
• Workflows on @latest will drift across major versions and sometimes blow up (seemingly at random). We should not allow this.

Solutions

I suggest this:

• Significantly de-prioritise the adaptor version across the Lightning UI. We should try to report versions as @4.x rather than listing the full patch version. The worker/runtime should continue to log the patch version.
• When running a job, always run it from the latest minor. This probably means that lightning sends versions with just a major, ie @4, and the Worker translates this to the latest patch.
• Show a security alert of some kind for workflows which are on an old major version. Maybe combine with an email alert. Basically we want to encourage manual migration for adaptors that are out of date
• Allow a workflow to be pinned to a specific patch version. This is a get out of jail free card. This is maybe a small button next to the adaptor version picker which opens up a dialog. It must be low in the hierarchy
• Maybe there isn't even a version picker - maybe for new steps the adaptor is auto-locked to latest, and there is one button to "pick a version" and one to "upgrade to latest" (which kicks off some sort of migration process). So we show the version as read-only, but provide buttons to change version, and make it feel like an advanced thing.

Start by reading #2843 and tracing how adaptor versions are represented across the Lightning UI and Worker/runtime. Turn the proposed versioning, security-alert, pinning, and migration ideas into an agreed scope; done means the long-term approach is decided and split into actionable implementation work.