ci: adjust 3.x branch references (#16358)

# Overview

Adapt the 3.x branch for its new role as the v3 maintenance line now
that v4 development has begun on `main`. Retargets release tooling, CI,
templates, and documentation links from `main` to `3.x`, and removes
workflows and GitHub surfaces that only fire from the default branch.

## Key Changes

- **Release tooling retargeted to 3.x**

  - `tools/releaser` creates GitHub draft releases against `3.x`.
- `create-payload-app` defaults its template, example, and
skill-download branch refs to `3.x`.
- `.github/workflows/main.yml` triggers on pushes to `3.x`; the no-op
`publish-canary` job was dropped.
- `.github/workflows/publish-prerelease.yml` drops the nightly cron and
the `canary` release type; on-demand `internal` / `internal-debug`
builds remain.

- **Default-branch-only workflows and surfaces removed**

- Deleted workflows driven by `schedule:`, `release:`, `issues:`, and
`pull_request_target:` events (activity-notifications,
audit-dependencies, dispatch-event, label-on-change, lock-issues,
post-release, post-release-templates, pr-title, stale, triage), along
with their exclusively-consumed custom actions (`activity`,
`release-commenter`, `triage`) and the orphaned `.github` pnpm
workspace.
- Deleted `.github/ISSUE_TEMPLATE/`, `PULL_REQUEST_TEMPLATE.md`,
`comments/invalid-reproduction.md`, and `dependabot.yml` — GitHub serves
all of these only from the default branch.

- **Docs, templates, and source links retargeted**
- Sweep of `github.com/payloadcms/payload/(tree|blob)/main/…` and
`raw.githubusercontent.com/payloadcms/payload/(refs/heads/)?main/…`
references across docs, READMEs, templates, examples, and test source,
rewritten to `3.x`.
- Also handles URL-encoded `%2Fpayload%2Ftree%2Fmain%2F…` forms (e.g.
Vercel deploy-button links) and the one-click-deploy link added
post-rebase in 5a39afc.
- Left untouched: `shields.io` workflow-filename badges (reference
`main.yml`, not a branch), cross-repo
`payloadcms/website/refs/heads/main/…` links, and all `main` workflow
files on `main` itself (this PR is scoped to 3.x).

- **Template variations regenerated**
- `pnpm script:gen-templates` output against workspace 3.84.0: bumps
`payload`, `@payloadcms/*` deps in template `package.json` files,
refreshes `importMap.js` for admin-rendered templates, and re-timestamps
the initial migrations for `with-postgres`, `with-vercel-postgres`, and
`with-vercel-website`.

## Design Decisions

- **Per-branch hardcoding over runtime branch detection.** Each branch
hardcodes its own ref (`3.x` here, `main` on v4). Simpler than
branch-aware logic, trivially reviewable, and the Phase 2 swap (v4 →
`latest`) stays a small diff.
- **Delete dormant workflows rather than trim triggers.** Workflows
whose only triggers are default-branch-only were removed entirely along
with their private actions. Leaving hollowed-out files on 3.x would
imply functionality that never fires. Removing them also shrinks
`dist`-bundle noise (~88k of the line-deletion count is pre-built action
bundles).
- **Discord release notifications stay on `main`.** Release events
always run from the default branch regardless of where the release was
cut, so `main`'s `post-release.yml` continues announcing both v3 patches
(from 3.x) and v4 betas. No 3.x-side copy is needed.
- **No npm dist-tag collision in Phase 1.** 3.x stays on `latest`;
`main` will publish v4 betas to `beta`. Phase 2 renames the 3.x package
to `payload-3`, freeing `latest` for v4 — so no per-major dist-tag
scheme is needed.

## Overall Flow

npm channels during Phase 1:

| Branch | Stable dist-tag | Scheduled | On-demand |
| --- | --- | --- | --- |
| `3.x` | `latest` | — | `internal`, `internal-debug` |
| `main` | `beta` | nightly `canary` | `internal`, `internal-debug` |

Release events (draft-release publish) always dispatch from the default
branch — which is `main` — regardless of where the release was cut. A v3
patch published from `3.x` therefore flows through `main`'s post-release
workflows:

```mermaid
sequenceDiagram
    actor Dev as Maintainer
    participant ThreeX as 3.x branch tooling
    participant NPM as npm
    participant GH as GitHub
    participant MainWF as main's post-release.yml
    participant Discord

    Dev->>ThreeX: pnpm release (v3.x.y)
    ThreeX->>NPM: publish at latest
    ThreeX->>GH: create draft release (target 3.x)
    Dev->>GH: publish release
    GH->>MainWF: release:published (fires from default branch)
    MainWF->>MainWF: release-commenter filters tag major (v3)
    MainWF->>GH: comment on v3 PRs/issues
    MainWF->>Discord: announce release
```

The same workflow path handles v4 releases from `main`, with the
release-commenter filtering to `v4` tags.

Author: denolfe