Duplication of state loading

This is a small tech-debty issue but I want it out of my head while I do other things

The loading of initial state is currently handled both by the worker (which makes sense, it knows about lightning and how to load state) and the runtime (which kinda makes sense, just like it need to lazy-load credentials before a job starts, it may also need to lazy load initial state).

I don't think we need the behaviour in both places. I want it in one place where it's easy to monitor.

It probably just needs to live in the runtime, so it can decide when and how to fetch initial state.

A good use-case is the CLI: what if we later want to run a lightning workflow from the CLI, or even claim an attempt through the CLI? The CLI will need the ability to resolve a dataclip id to a state object.

I think it makes sense that the runtime decides WHEN to load initial state, but the wrapping runtime manager (the CLI or worker) decides HOW (for example the CLI may want to cache the data)

The issue names no files or tests; start by tracing where initial state is loaded in the worker and runtime. Then map the runtime manager boundary, including the CLI path. Done means the runtime decides when to load state while the worker or CLI decides how to fetch or cache it, with no duplicated loading behavior.