Automate task + nodejs pin freshness (dated oracle, apt install unchanged)

[dtump]

Problem

task and nodejs are manual ARG pins in the Dockerfile, not part of update_pins.py's automated pins/*.env flow. They only get a passive drift reminder in the weekly pins-updater.yml PR body (⚠ needs your eyes) — nobody has to act on it, and nothing bumps them without a human specifically doing so. In practice that means these two can go stale for a long time relative to the other five automated tools.

Both are manual for the same underlying reason: update_pins.py's soak-gate needs a dated release feed to know a candidate version has survived N days before trusting it, and their current install sources don't expose dates:

• task installs from Cloudsmith's apt Packages index — no publish dates in the index.
• nodejs installs from NodeSource's apt Packages index — same problem.

Suggestion

Keep both install mechanisms exactly as they are today (apt, signed repos — no reason to give that up) and just fix the missing date source by cross-referencing a second, dated feed for the same version numbers:

• task: go-task/task publishes real GitHub Releases with published_at timestamps, using the same version strings Cloudsmith serves. Verified today: v3.53.1 (the currently pinned version) shows published_at: 2026-08-18T15:41:59Z via gh api repos/go-task/task/releases. Use that as the soak-gate oracle while apt-get install task=<version> stays the install mechanism.
• nodejs: nodejs.org/dist/index.json carries a date field and an lts field per release, for the same version numbers NodeSource repackages. Use that as the soak-gate oracle (and optionally restrict candidates to lts releases, so a bump can't jump to a new major unexpectedly) while the NodeSource apt repo stays the install mechanism. Needs one extra check: confirm NodeSource has actually packaged the candidate version before selecting it, since there can be a lag between the upstream release and NodeSource's repackage.

go isn't included here — no dated public feed was found for it (go.dev's JSON feed has no dates, and golang/go doesn't publish real GitHub Releases), so it likely has to stay a manual/reminder-only pin regardless.

Scope note

This is about pin freshness (closing the "stays stale unless someone remembers" gap), independent of #45 (extending the runtime version-assertion check) and #46 (CVE scanning via Trivy) — it doesn't replace either of those.

Per this repo's OpenSpec-first convention, this should go through an OpenSpec proposal before any Dockerfile / update_pins.py changes, not be implemented directly off this issue.

[dtump]

Related: #51 covers the same "pin outside the automated flow" problem for npm, which PR #50 introduced as a Dockerfile-inline pin while clearing 8 CVEs in npm's vendored dependencies.

npm is the easy case relative to the two here — it needs none of this issue's dated-oracle work, since the npm registry already exposes publish dates and kind="npm" already works for pnpm. It is also currently worse off: task and nodejs at least appear in the ⚠ needs your eyes reminder, while npm appears in no category at all.

Both issues land on the same surface (TOOLS, fragment_lines, and version-pin-refresh's enumerated npm tools plus its manual-pin reminder requirements), so one OpenSpec change could cover all three pins if that suits.