ci: pin latest LLGo main revision

[zhouguangyuan0718]

Summary

Update the default LLGo binary-size benchmark pin from d726187c to the latest xgo-dev/llgo:main merge commit 9b3f60c1.

This is intentionally a one-line version update; the existing workflow and Pages history remain unchanged.

Validation

• verified 9b3f60c1 exists on xgo-dev/llgo:main;
• git diff --check passed for the one-file diff.

[fennoai]

Review summary

This PR advances the pinned LLGo revision in ci/llgo-size/llgo-version.env from d726187… to 9b3f60c1ad555ae190f4545b9b1acad4899e598f — a one-line config change that deliberately triggers the binary-size benchmark workflow, exactly as the file's own comment describes.

I ran code-quality, performance, security, and documentation-accuracy passes over the diff. No blocking issues found.

• Well-formed pin: the new value is a valid 40-char lowercase hex SHA, satisfying the workflow's ^[0-9a-f]{40}$ validation. The .env syntax stays valid for source, and LLGO_REPOSITORY, GO_VERSION, LLVM_VERSION are untouched.
• Supply chain: the new SHA is a real, ancestrally-linked commit on xgo-dev/llgo (a merge commit whose first parent is the previous pin) — a normal forward advance on the official upstream, not a redirect to a fork or unrelated history. It is an immutable pin, not a mutable branch/tag.
• Docs: no documentation quotes either the old or new SHA, so README.md / docs/llgo-binary-size-handoff.md remain accurate. report.sh reads the value from the environment at runtime and is unaffected.

Notes (non-blocking, not introduced by this PR)

• The file comment asks to keep the revision "compatible with GO_VERSION and LLVM_VERSION". Whether 9b3f60c… actually builds against Go 1.26.2 / LLVM 19 can only be confirmed by the CI run itself — not verifiable from the diff. Please confirm the workflow passes before merging.
• Pre-existing hardening opportunity in .github/workflows/llgo-binary-size.yml: the workflow declares top-level permissions: contents: write and runs on pull_request. The secret-bearing publish/deploy steps are correctly gated to non-PR events, so a forked PR cannot reach them — but least privilege would favor a default contents: read at the top level, elevating only within the publish step. This is unrelated to the current diff and neither introduced nor worsened by it.