ci: switch test-link trigger from pull_request_target to pull_request

[ryantm]

Why

The recent TanStack NPM supply-chain compromise was carried out via a pull_request_target workflow. As a precaution, we are removing pull_request_target triggers from all Replit-owned public repos so that no workflow runs with write-scoped repo secrets against fork-controlled inputs.

The current test-link.yml workflow uses pull_request_target so that fork PRs also get an auto-appended raw.githack.com web-demo link in the PR description. It only uses actions/github-script and never checks out PR head code, so the immediate exposure is limited — but per policy we're removing the trigger entirely rather than relying on the workflow staying safe under future edits.

See also Slack thread: https://replit.slack.com/archives/C03FS477T17/p1778588219046429

What changed

• .github/workflows/test-link.yml: switched the trigger from pull_request_target: to pull_request:. Nothing else in the workflow changes.

Tradeoff: With pull_request, the workflow runs against the fork's code with a read-only GITHUB_TOKEN, which cannot edit the PR description. In practice this means:

• Internal PRs (branches in replit/codemirror-vim): still get the auto-appended web-demo link, exactly as before.
• External / fork PRs: no longer get the auto-appended link in the description.

If we want fork-PR support back, the recommended replacement is either a separately-gated GitHub App, or a workflow split into two parts (an unprivileged pull_request job that produces the link as an artifact, plus a privileged workflow_run follow-up that posts a comment — not edits the description) so it never runs untrusted code with write permissions.

Test plan

• This change only edits a workflow trigger; the workflow body is unchanged.
• After merge, opening an internal PR should still trigger the "Update PR Description" workflow and append the raw.githack.com link. Opening a fork PR will no longer auto-append the link (expected per the tradeoff above).

Revertibility

Safe to revert — it's a single trigger change in a single workflow file with no data migrations or protocol changes. Reverting restores the previous behavior of auto-appending links on fork PRs (and reintroduces the pull_request_target exposure).

---

~ written by Zerg 👾 (morphing-hellion-0ea0)

Open web-demo @ 10b40d1308f2b94cd433171be53a1b415f552cf7