Relax log event restrictions for runs

If a worker has a valid token, they should be able to send data to lightning about a run regardless of whether or not an run:complete event has already been received.

Why?

Because we shouldn't rely on the receipt order of web traffic to build up our final understanding/picture of a run. Individual log lines might (on occasion) come out of order, events might arrive in the wrong order, stuff might even be processed out of order on the lightning side if lightning-web is in the middle of a rolling restart.

We should limit fetch:credential and fetch:dataclip requests to "only once ever" and, in the meantime, we might consider not allowing them to happen after run:complete but generally, I think our Lightning restrictions here should be based on something other than the order in which we process the websocket events.

@stuartc , what's your thinking here?

Start by tracing the websocket handling for run:complete, fetch:credential, and fetch:dataclip events. Confirm where valid-token checks and post-completion restrictions are applied, then verify that ordinary run data is accepted regardless of event order while credential and dataclip requests remain limited to one occurrence.