fix(ci): repair invalid expressions breaking ci.yml and docker.yml on every push to main

[Junirezz]

Closes #931

---

What's broken

Both .github/workflows/ci.yml and .github/workflows/docker.yml have been failing on every single push to main since at least July 25 -- verified across 15+ merge commits. Not because a job's steps actually failed, but because both files contain invalid GitHub Actions expressions that GitHub rejects before scheduling any jobs at all. Confirmed via the GitHub API: both failing runs show jobs: [] and zero billable minutes -- a startup-level rejection, not a runtime failure.

ci.yml

Every job (node-ci, sdk, frontend, rust-ci) used the runner context inside a job-level env: block:

env:
  COMMAND_LOG_DIR: ${{ runner.temp }}/bridge-watch-command-logs/node-ci

The runner context isn't available at job-level env: -- it only becomes available once a runner has actually been provisioned (i.e. inside step-level env:/run:), which is exactly why GitHub rejects the whole workflow file before any job can start.

Fix: removed these two vars from job-level env: in all four jobs, and instead compute them inside each job's existing "Initialize command log archive" step (already the first step in every job) using the shell-native $RUNNER_TEMP variable, exporting them via $GITHUB_ENV so every later step in the job sees them exactly as before.

docker.yml

tags: ${{ id.meta.outputs.tags }}
labels: ${{ id.meta.outputs.labels }}

id isn't a valid expression context. The step is id: meta, so its outputs live under steps.

Fix: id.meta.outputs.* -> steps.meta.outputs.*.

Verification (actually run, not assumed)

• Installed actionlint (a GitHub-Actions-schema-aware linter, not just generic YAML validation) via its official release binary and ran it against both fixed files: zero errors on either.
• Re-ran actionlint against every workflow file currently in .github/workflows/ as a full sweep, to confirm nothing else in this class of bug exists repo-wide. The only remaining findings are pre-existing, unrelated, info/style-level shellcheck nits in three already-passing workflows (code-quality.yml, release.yml, release-dry-run.yml, load-testing.yml), which I left untouched -- out of scope, and those workflows aren't failing.
• Confirmed via the GitHub REST API (workflow run history, per-job breakdown, check-suites) that these failures are independent of any recently merged PR -- every merge to main since July 25 shows the identical zero-job failure signature, including merges that long predate this PR.

Other currently-red workflows on main -- not touched here, and not fixable by a code PR

While auditing every workflow's latest status on main, I found three more that are currently failing, but for reasons no code change can fix:

• db-backup.yml -- depends on real POSTGRES_*/AWS_* secrets. Its "Run backup" step is the failure point, consistent with those secrets being unset or pointing at infrastructure this project doesn't actually have configured. A secrets/ops decision for a repo admin, not a workflow bug.
• dependency-update.yml -- both jobs get through every step and fail specifically at "Create Pull Request" (peter-evans/create-pull-request@v6). That's the textbook signature of the repository's "Allow GitHub Actions to create and approve pull requests" setting being disabled -- a Settings toggle only a repo admin can change, not something in the YAML. Two pre-existing branches (chore/npm-dependency-updates, chore/cargo-dependency-updates) already exist and may also be blocking re-creation.
• deploy.yml -- triggers via workflow_run: ["Docker Build & Push"], i.e. it's chained off docker.yml. Since docker.yml has been failing its startup check, deploy.yml has simply never fired since -- once this PR lands, it should start running again. Its last real failure (March) predates that and is most likely a GitHub Environment approval-gate issue, since the "Deploy to Production" step is literally just a placeholder echo, not real deployment logic.

Happy to take a pass at any of those three if you can confirm whether the relevant secrets/settings are meant to be configured, or whether this project doesn't have that infrastructure in the first place.

[Mosas2000]

Please fix the failing checks.