deploy: reuse a green verdict when the tree is identical

[sixvolts]

GitHub's merge button always mints a new commit, so a merge SHA never has a run of its own even when the branch it came from was exhaustively tested. The gate is SHA-keyed, so it found nothing and waited for main's own run - roughly eight minutes of ceremony whenever main had not moved, because the merge commit was byte-identical to the branch tip under a new id.

Ask the content instead. If some commit with the SAME TREE already has a green run for the gate workflow, reuse that verdict.

The tree hash draws the line exactly where it should. main did not move while the branch was in flight, so the trees match and re-running proves nothing new. main DID move, so the merge commit is the branch plus whatever main gained, the trees differ, no verdict is reused, and the normal wait applies - which is right, because that combination has genuinely not been tested. That is the case the pull_request trigger used to cover before it was dropped, and the post-merge run is now the only thing catching it.

Deliberately narrow: the tree lookup can only ever return success. A non-success on a DIFFERENT commit says nothing about this one, so failure and pending still come solely from the SHA-based ladder, and a real failure for this SHA still short-circuits before the tree is ever consulted. Nothing here can turn a red deploy green.

Limitation worth stating plainly: identical trees mean identical SOURCE, not an identical environment. A test that depends on wall-clock time, prior database state, or a model's output could pass on one commit and fail on another with the same tree. That risk is already present in trusting the branch run at all; this adds a new place it applies, not a new kind of risk.

Verified against real data before committing, with three cases: the current main tip resolves to its own run; a synthetic commit sharing main's tree and having NO run of its own still resolves (the merge case); and a commit with a novel tree correctly resolves to nothing. The first attempt carried the matching sha out through a global, which silently did not work because the function runs in a command substitution - a subshell - so it returns the sha on stdout instead.