This is a comment left during a code review.
Path: .github/workflows/ci.yml
Line: 463-475

Comment:
**Heredoc terminator will never be matched**

The Python code and its heredoc terminator (`PY`) sit at 12 spaces of YAML indentation, while the surrounding shell body (e.g. `set -euo pipefail`, `BASE="$("`) sits at 10 spaces. Because `run: |` is a YAML literal block scalar that strips those 10 spaces of common indentation, the shell actually receives the terminator as `  PY` (2 leading spaces), not `PY` at column 0.

For a `<<'PY'` heredoc (no `-` modifier), bash only recognises a terminator that is **exactly** at column 0 with no surrounding whitespace. `  PY` is never matched, so bash reads through the rest of the script looking for the terminator and eventually hits EOF, producing an "unexpected end of file" error that breaks the entire `secrets` job.

There are two problems that need to be fixed:

1. **The terminator indentation** – the `PY` line (and the whole Python body) must be placed at the same indentation level as the surrounding bash code (10 spaces in the raw YAML) so that after YAML stripping they appear at column 0.

2. **Python top-level indentation** – after YAML stripping the Python lines all start with 2 spaces, which Python 3 rejects with `IndentationError: unexpected indent` on the very first `import` statement.

The existing iOS job (lines ~725-798 in the same file) uses the correct pattern: the Python body and its `PY` terminator are at the **same** YAML indentation as the surrounding shell code, not at a deeper level.

A corrected version of this block:

```
        BASE="$(
          python - <<'PY'
import json
import os

with open(os.environ["GITHUB_EVENT_PATH"], "r", encoding="utf-8") as fh:
    event = json.load(fh)

if os.environ["GITHUB_EVENT_NAME"] == "push":
    print(event["before"])
else:
    print(event["pull_request"]["base"]["sha"])
PY
        )"
```

(The Python source lines and the `PY` terminator must be flush against the left margin of the YAML `run:` block — i.e., at the same raw indentation as `set -euo pipefail`.)

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: src/infra/gaxios-fetch-compat.ts
Line: 268-271

Comment:
**Concurrent callers during `"installing"` resolve immediately**

When `installState === "installing"`, any concurrent `await installGaxiosFetchCompat()` call short-circuits and returns a resolved `Promise<void>` before installation actually finishes. Code that follows the `await` in those concurrent callers may run against an unpatched gaxios prototype.

This is benign for the current sequential startup callers (`entry.ts`, `index.ts`), but the guard silently drops the wait contract for any future caller that does:

```ts
await installGaxiosFetchCompat();
// assumes gaxios is patched here – not guaranteed if a concurrent install is in flight
const result = await new Gaxios().request(...);
```

A simple future-proof alternative is to cache the in-flight Promise so all concurrent callers coalesce onto it:

```ts
let installPromise: Promise<void> | null = null;

export function installGaxiosFetchCompat(): Promise<void> {
  if (installState === "installed" || installState === "shimmed") return Promise.resolve();
  if (typeof globalThis.fetch !== "function") return Promise.resolve();
  installPromise ??= (async () => {
    installState = "installing";
    try {
      // ... existing body
    } catch (err) {
      installState = "not-installed";
      installPromise = null;
      throw err;
    }
  })();
  return installPromise;
}
```

Not blocking the PR given current callers are sequential, but worth addressing before this module is used in any concurrent context.

How can I resolve this? If you propose a fix, please make it concise.