#1770 A run's terminal status reaches the shared datastore only when a later run happens to push it

With an S3-backed shared datastore, a serve-executed workflow run's start record is pushed promptly, but its terminal status is not: the bucket copy of the most recent run stays running with no completedAt indefinitely, and only flips when later run activity happens to push the by-then-dirty record. Expected: a completed run's terminal status reaches the shared datastore at latest on the executing host's next push.

Field evidence (swamp 20260820.072114.0, @swamp/s3-datastore 2026.08.12.1, serve executing scheduled workflows; bucket objects fetched directly):

• Run A: started 12:47:52, completed 12:48:40. Bucket record shows succeeded — but its object's LastModified matches run B's pushes, not run A's completion.
• Run B (the last run of the day): started 12:54:50, completed minutes later. Bucket object LastModified 12:54:53 — three seconds after start — status: running, no completedAt. Hours later, unchanged.

Every other participant syncing the bucket sees run B as running forever (until unrelated future activity on the executing host pushes it). Remote workflow history can therefore never answer "is something running right now?" for the newest run.

This is consistent with pushes riding method executions: the run's terminal status is written after the run's final method push, so no push ever carries it. If that's the design, a run-completion push (or including the run record in a completion-time flush) would close the gap.

Repro: repo on an S3 datastore, serve on host A, run any workflow to completion via serve; GET workflow-runs/<wf-id>/workflow-run-<run-id>.yaml from the bucket (or sync a second clone and run workflow history search). The record reads running. Run a second workflow: the first's terminal status now appears; the second's is stranded.