chore: standard issue templates + label-automation dispatchers

[chrisferry]

Org-standard YAML issue forms (native type: Bug/Feature/Task, status:untriaged, this repo's component:* default, dropdown where multi-component) replacing the legacy .md templates, plus SHA-pinned dispatchers for the shared reusable label workflows. node-release-checklist.md is preserved.

Also in scope:

• CODEOWNERS: the enumerated .github rules collapse into a single /.github/ rule, so security and SRE own everything under .github rather than a fixed list that new files fall outside of. The previous rules had real gaps — /.github/workflows/dependabot.yml matched nothing (that file lives at .github/dependabot.yml), and three of the owned paths are .md templates this PR deletes.
• Fork PRs: ai-assisted-label moves to pull_request_target, because GitHub gives fork-originated PRs a read-only token on pull_request and this repo takes external contributions regularly. Safe here — the reusable never checks out or executes PR code.

Dispatchers call the public midnightntwrk/workflows reusable library, pinned to a SHA. Verified live: the re-pointed ai-assisted-label dispatcher resolves and runs green, which the previous private-.github route could not do from a public repo.

Closes #2027

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a1806cdfd7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Use a writable trigger for fork-originated PRs

For PRs opened from forks or by Dependabot, GitHub downgrades the pull_request event's GITHUB_TOKEN to read-only despite the requested pull-requests: write permission. The called reusable workflow therefore cannot add or remove bot:ai-assisted for those PRs; use a safely designed writable context such as pull_request_target, or another trusted-token mechanism, so the repository's AI-label requirement is enforced for external contributions too.

AGENTS.md reference: AGENTS.md:L178-L183

Useful? React with 👍 / 👎.

[chrisferry]

Codex P2 applied, after checking both halves of it — the risk and the need.

The need is real. This repo has taken 8 fork PRs in its last 100, so external contribution is current practice, not hypothetical. On pull_request, GitHub hands fork-originated PRs a read-only GITHUB_TOKEN regardless of the pull-requests: write we request, so bot:ai-assisted was never being applied to any of them. The reusable's own header had already predicted this ("Fork PRs would not be labeled — revisit if external forks become common") — that condition is now met.

The risk is not. pull_request_target is dangerous when a workflow checks out and executes PR code with a privileged token. This one cannot: the reusable runs a single actions/github-script step, performs no checkout, and only reads PR metadata (body + commit messages) through the API. Untrusted text is regex-tested in JS, never passed to a shell. So the trigger switch buys the write token without opening the usual pull_request_target hole.

actionlint clean. Committed normally, not force-pushed, per AGENTS.md.

---

Separate, larger finding while verifying the above — the backstop cannot detect this repo's own mandated disclosure format.

The reusable matches on:

(co-authored-by:.*(claude|anthropic\.com|codex|openai|copilot|cursor|gemini|gpt-[0-9]))
| (generated (with|by) .*(claude|codex|copilot))
| 🤖 generated (with|by)

But AGENTS.md:179-181 explicitly forbids Co-authored-by for LLM tools and mandates Assisted-by: AGENT_NAME:MODEL_VERSION instead — which matches none of those alternatives. So a PR that follows this repo's convention exactly is invisible to the automatic labeller, and the backstop only fires for authors using the format the repo tells them not to use.

That is a fix in the shared reusable rather than here, so it is out of scope for this PR. Raising it so it is not mistaken for working once this merges.

[chrisferry]

Update on the Codex P2 (fork PRs) — it collides head-on with this repo's own security gate, so I have reverted it and need a decision.

I applied pull_request_target as recommended. zizmor then failed the scan check with an error:

.github/workflows/ai-assisted-label.yml:10
use of fundamentally insecure workflow trigger:
pull_request_target is almost always used insecurely

So the two automated reviewers directly contradict each other: Codex says use pull_request_target to enforce the AI-label requirement on external contributions; zizmor blocks that trigger unconditionally and gates the merge.

My read is that zizmor's rule is a blanket heuristic and this is one of the cases where it is a false positive — pull_request_target is dangerous when a workflow checks out and executes PR code with a privileged token, and this reusable does neither (one actions/github-script step, no checkout, PR metadata read through the API, untrusted text only regex-tested in JS). But suppressing a security gate is not a call to make quietly inside a templates PR, so I have reverted to pull_request and documented the gap in the file. scan is green again.

The three ways forward:

1. Accept the gap (current state). Fork PRs are never auto-labelled; external contributors rely on reviewer enforcement. Zero risk, requirement not mechanically enforced for forks — which is precisely what Codex objected to.
2. Suppress the rule — pull_request_target plus a scoped # zizmor: ignore[dangerous-triggers] with the justification above. Closes the gap; needs security sign-off, and sets a precedent others may copy into workflows that do check out PR code, where it would be genuinely unsafe.
3. Use workflow_run — the pattern GitHub actually recommends for needing a write token on fork PRs. zizmor-clean and structurally safer, but it is a redesign of the shared reusable (the PR number is not in the event payload, so it has to be recovered by head SHA) and would land fleet-wide, not just here.

@midnightntwrk/mn-security — this one is yours. Option 1 is in effect until someone says otherwise, so this PR is not blocked on it.

Separately, the disclosure-regex gap I flagged above still stands and is arguably the bigger issue: the reusable cannot match Assisted-by:, the format AGENTS.md actually mandates, so the labeller is blind to correctly-formatted PRs regardless of which trigger is used.