upload-asset: concurrent runs race on the shared assets branch (single non-retried push)

[strawgate]

The upload-asset safe-output publishes to a shared assets/${{ github.workflow }} branch. The generated upload_assets job does:

git checkout -B <branch> origin/<branch>
git add / git commit
git push origin <branch>        # single attempt, no fetch/rebase/retry

When two runs of the same workflow finish near-simultaneously, both snapshot the branch at the same SHA, both commit, and the second push is rejected:

! [rejected]  assets/<workflow> -> assets/<workflow> (fetch first)
error: failed to push some refs
hint: Updates were rejected because the remote contains work that you do not have locally

That run's upload_assets job fails and its asset never lands, so an embedded ![](<url>?raw=true) image URL 404s.

This is latent for single-instance (scheduled) workflows, but reproducible for any workflow that runs multiple instances concurrently, e.g. triggered per pull-request or per comment. Repro: a workflow with a per-PR trigger and a default upload-asset:, fired on several PRs so the runs finish together; one upload_assets job fails with the rejection above.

Suggested fixes (either/both):

1. Make the push conflict-tolerant: on non-fast-forward, git fetch and replay the new file(s) onto the updated tip (or a bounded git pull --rebase retry loop). Each run only adds distinct files, so a rebase is always clean.
2. Optionally include a per-invocation identifier (run id / PR number) in the branch or file path so concurrent runs don't target the same ref.

Environment: gh-aw v0.85.x (engine-independent).