chore: ARC process reduction

Replace the six stage-specific PR templates with:

- `arc-draft.md` for a new ARC;
- `arc-status-change.md` for any status change, with the remaining human
  checks grouped by target status;
- `arc-update.md` for adoption, implementation, and editorial updates.

Machine-checkable gates already run in CI, so the templates only ask for
what a person has to confirm.

The `kind:*` label now comes from the changed files instead of PR template
headings: a new ARC file is `kind:draft`, a status change to `Review`,
`Last Call`, or `Final` gets the matching label, other adoption changes are
`kind:adoption`, and other ARC edits are `kind:editorial`. Labels stay
correct when the author picks the wrong template or edits its heading.

For a `Last Call` to `Final` status change, the transition step reads
`last-call-deadline` from the base branch (Final ARCs must drop the field)
and fails when it is missing or still in the future (UTC).

ARC-0000 now passes every arckit rule without exemptions, so its entry is
removed from `.arckit.jsonc`:

- add the missing `Motivation` section (R:008);
- wrap illustrative `ARC-42` examples in code spans and refer to "this ARC"
  instead of `ARC-0000` (R:036);
- record the 2026-11-02 update.

ARC-0000, the ARC template, and the adoption README now treat the adoption
summary as optional in `Draft` and `Review` and required from `Last Call`,
matching what arckit already enforced. They also describe adoption readiness
as derived from tracked adopters rather than declared, and drop
`last-reviewed`.

Generated by `arckit fmt adoption/arc-*.yaml`; no other content changes.

Adoption summaries no longer declare `last-reviewed` or
`summary.adoption-readiness`:

- validation rejects both fields with the new auto-fixable rule R:039;
- `arckit fmt` deletes them;
- `summary repo` derives adoption readiness from the tracked adopter count
  (low < 3, medium 3-4, high >= 5) for its distribution table and the top
  ARCs table, and drops the stale-review table that relied on
  `last-reviewed`;
- `init arc` and the adoption template no longer emit either field.

ci: maintenance

chore(deps): bump https://github.com/rvben/rumdl-pre-commit from v0.2.77 to 0.3.2

`maintenance:authors-action` and `maintenance:editor-action` were defined as
policy vocabulary but never applied by any workflow.

- never @-mention ARC authors in suggested status transitions;
- stop reporting missing or malformed tracking issues (the PR process check
  already enforces them);
- report online link findings only in the workflow summary; they no longer
  appear in, or open, the monthly issue;
- omit empty report sections instead of printing placeholders;
- keep the ARC state summary out of the issue (workflow summary only);
- never rewrite an existing monthly issue on re-runs;
- stop suggesting `Idle` for inactive `Final` ARCs, which was mostly false
  positives.

The ARC process check already locates the tracking issue by ARC number and
`arc-tracking` label, so also requiring the PR body to reference it was pure
paperwork. The check still fails when the tracking issue is missing,
malformed, or unlabeled.

When a changed ARC file changes `status` relative to the base branch, PR
validation now runs `arckit validate transition --from <old> --to <new>`.
This enforces the machine-checkable gates (required sections, reference
implementation status, adoption summary) and rejects skipped gates such as
`Draft` to `Final`.

Moves that ARC-0000 allows without a forward gate (`Last Call` to `Review`,
`Idle` to `Final`, and any move to `Draft`, `Stagnant`, `Withdrawn`,
`Deprecated`, or `Living`) are not validated.

`validate transition` expected the ARC file to still carry its pre-transition
status, so it could not run on a pull request that already flips `status`.

With `--from <status>`, the file is validated in its post-transition state:
the previous status is taken from the flag, the file must carry the target
status, and `last-call-deadline` is no longer required for `Final` (R:033
forbids it there).

chore(deps): bump the minor-and-patch group with 2 updates

chore(deps): bump the minor-and-patch group with 3 updates