[feat] Define the team revision once for run records, labels and snapshots #1163

Parent: #818

Goal

Three issues publish a teamRevision, and none defines it:

• [feat] Add workflow scorers and recorded quality labels #1085 locked it in the label record ("which version of the rubric gave each label");
• [feat] Publish and resume complete workflow state across machines #1084 records it in the state snapshot;
• [feat] Add a Workflow Runs page to the dashboard #1088 shows it on the Workflow Runs page.

Define it once, capture it once, and publish it in the run record (#1083) so the other three read the same value.

The obvious answer is wrong

git rev-parse HEAD in the team repo at workflow start does not say what ran:

• A run executes the definition cached at pull (src/workflow/cache.ts), not the files at HEAD.
• When a newer version fails validation, the cache keeps the earlier valid one. HEAD then holds a definition the run did not execute.
• In self mode, pull can cache edits that were never committed, or committed and never pushed. No teammate can resolve such a commit.
• sourceHash already identifies what ran exactly: the YAML plus its prompt files, with children combined (engine.ts, loadWorkflows). It is a hash, not something a person can open.

Definition

How the value is captured:

• At pull, cache.ts stores the team repo commit of that pull in every entry it writes or confirms unchanged. It does this only when the entry's files have no changes and the commit is reachable from a remote-tracking ref.
• An entry kept from an earlier pull keeps its earlier value, because its content is not at the current HEAD.
• A run has a teamRevision when its parent and every child workflow carry the same one. Otherwise it has none. Never guess one.

The run record publishes both fields in the start and end phases. #1085 applies the same rule to the scorer file, and #1084 and #1088 read it from the run.

Acceptance criteria

Checked against git, not against our own code:

1. In a fresh clone of the team repo, git cat-file -e <teamRevision> succeeds for every published value.
2. git show <teamRevision>:workflows/<name>.yaml, hashed with its prompt files the way cache.ts hashes them, equals the run's sourceHash for a run without children.
3. A workflow edited and pulled without a commit publishes sourceHash and no teamRevision. The same happens when it is committed but not pushed.
4. A newer version that fails validation leaves the kept entry with its earlier teamRevision, and a run of it publishes that earlier value.
5. A parent and a child cached at different commits produce a run with no teamRevision.
6. A record published before this change still parses and merges, and a record with the new fields parses with today's WorkflowRunRecord reader.
7. Over the published records, jq -r '[.run, .sourceHash, (.teamRevision // "-")] | @tsv' workflows/runs/*.json on teamai-reports groups runs of the same definitions under one sourceHash, and names the commit when there is one.

Test plan

• Unit tests in cache.ts for each case above, with a real git repo and a bare origin. That is cheaper than mocking git.
• Extend the e2e workflow-records-reports-branch-1083.test.ts: read teamRevision from the record on origin, then run criteria 1 and 2 against the fixture's clone.
• One real-CLI run for the PR body: teamai pull, then teamai workflow start <name> --driver local, then criteria 1 and 2 checked on a fresh clone.

Watch out for

• The run lock forbids network I/O. Reading a remote-tracking ref is local; never fetch inside pull's cache step for this.
• docs/guide/workflow.md and its zh-CN page: add both fields to the "Run records" list.
• feat(workflow): bounded loops, parallel for_each and list expressions #1148 (for [feat] Add bounded loops and parallel for_each #1079) rewrites cache.ts and records.ts. Start after it merges, or rebase onto it.

Out of scope

The CI job URL (until a reader needs it) and PR URLs (#1090 publishes delivered PRs).

Dependencies

• Blocked by: [feat] Publish privacy-preserving workflow run records and stats #1083
• Unblocks: [feat] Publish and resume complete workflow state across machines #1084, [feat] Add workflow scorers and recorded quality labels #1085, [feat] Add a Workflow Runs page to the dashboard #1088