eas workflow:run --ref discards the branch name (resolved to a SHA locally before dispatch)

### Summary

`eas workflow:run --ref ` resolves the ref locally with `git rev-parse` and sends only the resulting SHA, so the branch name never reaches the server. Triggering the same workflow from the dashboard's "Run workflow" button stores the branch name correctly, so the branch is lost on the CLI path only.

### Managed or bare?

Managed (CNG) — `ios/` and `android/` are gitignored and generated by prebuild.

Note: `npx expo-env-info` reports "bare" because the directories exist locally after a prebuild. Not relevant to this issue, which is CLI-side only.

### Environment

```
expo-env-info 2.1.0 environment info:
System:
OS: macOS 26.6.2
Shell: 5.9 - /bin/zsh
Binaries:
Node: 26.3.0
Yarn: 1.22.22
npm: 11.16.0
Watchman: 2026.06.08.00
Managers:
CocoaPods: 1.17.0
IDEs:
Xcode: 26.6/17F113
npmPackages:
expo: ~57.0.18 => 57.0.18
expo-router: ~57.0.17 => 57.0.17
react: 19.2.3 => 19.2.3
react-native: 0.86.3 => 0.86.3
npmGlobalPackages:
eas-cli: 23.0.0
```

`npx expo-doctor`: 21/21 checks passed. No issues detected!

### Error output

No error. The run succeeds; the branch name is silently dropped.

### Reproducible demo or steps to reproduce from a blank project

1. Create a blank Expo project, link it to a GitHub repo in EAS project settings, and push a branch named e.g. `my-branch`.
2. Add any workflow file, e.g. `.eas/workflows/build.yml` with a single `type: build` job.
3. Run: `eas workflow:run build.yml --ref my-branch`
4. In the dashboard, open **Workflows**. The run's **Branch** column shows a 40-character commit SHA, not `my-branch`. The **Git branch** filter fills with hashes and becomes unusable. On the **Builds** page, **Git ref** shows only the SHA.
5. Now trigger the same workflow via the dashboard's **Run workflow** button, selecting `my-branch`. That run shows `my-branch` in the same column.

Both runs have `triggerEventType: MANUAL` and build the same commit — only the CLI path loses the branch.

### Cause

In `packages/eas-cli/src/commands/workflow/run.js` (built output), `gitRef` is reassigned to the output of `git rev-parse flags.ref`:

```js
gitRef = (await spawnAsync('git', ['rev-parse', flags.ref], { cwd: projectDir })).output[0].trim();
```

and only that resolved value is passed to `createWorkflowRunFromGitRefAsync`. The original string survives only in error messages (`at ${flags.ref}`).

No input avoids this, since `rev-parse` collapses a branch name, a qualified ref (`refs/heads/...`) and `HEAD` to the same hash.

Since the dashboard path stores and renders branch names correctly, the server clearly handles them fine. Could the CLI send the original ref alongside the resolved SHA?

### Side effect

`github.ref_name` resolves to the SHA on CLI-dispatched runs, so workflows cannot report the branch in notifications (e.g. a Slack job). The same expression renders the branch correctly on dashboard-triggered runs.

### Separately: `--ref` appears undocumented

It is absent from the workflows guides (syntax, get-started, control-flow, automating-eas-cli) and appears only in `eas workflow:run --help` and the CLI README.

Start in packages/eas-cli/src/commands/workflow/run.js at the eas workflow:run --ref handling, then trace createWorkflowRunFromGitRefAsync and the git rev-parse call. Reproduce with a branch ref and compare CLI and dashboard runs. Done means the run preserves the branch name for the dashboard, Git ref, and github.ref_name while still building the same commit.

Written by the indexing model from the issue text.