chore(ci): gate PR Tests to main-targeting PRs only (silence v0.4 line)

[couragehong]

핵심은 feat/go-migration 으로 들어가는 PR은 CI가 안도는겁니다.

The Python pytest pipeline at .github/workflows/pr-tests.yml currently fires on every PR open / synchronize / reopen, regardless of base branch. Across the v0.4 Go migration line that's pure noise: every PR into feat/go-migration runs the v0.3 pytest suite against a working tree where the Python source is being deleted out from under it (Python tree removal already landed via PR #129). The runs all fail or no-op, which trains contributors to ignore CI status — the worst possible state to be in when CI matters again at main-merge time.

Narrow the trigger so the workflow only fires when the PR's base branch is main. That preserves the workflow scaffolding for the final feat/go-migration → main integration moment, when CI itself will be rewritten as Go (build / vet / fmt / test -race) so it actually exercises the v0.4 code at the boundary.

Effect on PR streams

PR base = feat/go-migration → no CI run (silent)
PR base = main → CI runs (existing pytest pipeline,
to be rewritten at main-merge)

pr-comment.yml is unchanged — it chains off workflow_run: workflows: ["PR Tests"], so when pr-tests stays quiet, pr-comment
stays quiet too. No edit needed there.

Side effects

• PR Couragehong/chore/ci drop python #125 (ci-drop-python) currently sits open and proposes a Go CI rewrite. With this gate in place there is no CI noise to fight, so Couragehong/chore/ci drop python #125's urgency drops. The cleanest path is to close it and redo the Go CI as part of the main-merge integration PR — that way the CI lands together with whatever the boundary actually needs (artifact uploads, GOPRIVATE auth, OS matrix, etc.) rather than having two CI rewrites land independently.
• .github/workflows/pr-tests.yml still references .github/scripts/ci_changed_tests.py and requirements.txt, both of which exist in main but not on feat/go-migration after PR chore: remove Python rune-mcp tree (v0.3 implementation) #129. That is intentional — the workflow scaffolding stays bound to main's contents, and the rewrite at main-merge time will replace both anyway.