i18n: custom-node and node-def translation workflows are disabled in Actions

## Problem

Two of the three i18n workflows exist on `main` but are disabled in GitHub Actions:

```
196119072 active .github/workflows/i18n-update-core.yaml
198587815 disabled_manually .github/workflows/i18n-update-custom-nodes.yaml
198587816 disabled_manually .github/workflows/i18n-update-nodes.yaml
```

Run history:

- `i18n-update-custom-nodes.yaml` — **0 runs, ever.**
- `i18n-update-nodes.yaml` — 2 runs, last `2026-08-11T04:01:26Z`, then disabled.

Both are `workflow_dispatch`-only, so a disabled state means they cannot be triggered
at all.

## Why it matters

`i18n-update-custom-nodes.yaml` is the custom-node localization pipeline: it installs a
third-party node pack, collects and translates its strings, extracts the delta with
`scripts/diff-i18n.ts`, and opens a PR against the node author's repository. It reads
as a shipping feature — it is documented, it has an e2e test
(`browser_tests/tests/customNodeLocales.spec.ts`, added in #12132), and it has been
maintained across several PRs — but it has never executed.

Two recent PRs did maintenance on these dead files:

- https://github.com/Comfy-Org/ComfyUI_frontend/pull/15062 added `fetch-depth: 0` and
`filter: blob:none` to both, so the new pipeline can resolve manifest blobs.
- https://github.com/Comfy-Org/ComfyUI_frontend/pull/15137 fixed the custom-node copy
path (`temp/diff`, not `ComfyUI_frontend/temp/diff`).

Neither could have been validated, because neither workflow can run.

## Decision needed

Either:

- **Re-enable them** and do one end-to-end dispatch against a real node pack. This is
the option that requires the most care: the workflow opens PRs on repositories we do
not own, so a mistake is visible outside the org. See also the `diff-i18n.ts` manifest
issue linked below.
- **Delete them** along with `scripts/diff-i18n.ts` and the e2e spec, and remove the
custom-node section from `src/locales/CONTRIBUTING.md`, so the repo stops implying a
capability that does not exist.

Whichever way, the state should be explicit rather than a disabled toggle nobody can see
from the source tree.