feat(languages): ship the missing python and typescript hooks

The python and typescript bundles carried rules and a coverage script but no pre-commit hook, so any project installing one got no credential scan on commit. Both now ship all four components the README documents: the shared secret scan, a validate-on-edit hook, settings wiring, and a seed CLAUDE.md. Verified against a real repo: a commit carrying an AWS key is refused.

install-lang now warns when a bundle is missing a documented component. That's the half that keeps this from recurring. Whoever adds the sixth bundle will forget something too, and today the installer prints success either way.

Two things fell out of the build. node --check is unusable on TypeScript: it ignores --experimental-strip-types, so it rejects valid TS and accepts broken TS. The hook uses tsc filtered to syntactic diagnostics instead. And completing the bundles means every pair now collides on settings.json and pre-commit, so no two compose without FORCE=1. The earlier "bundles already compose" reading rested on these two being incomplete. Filed for a real decision; clock-panel is the project that wants it.

Also stamps :LAST_REVIEWED: at task creation, with a lint checker to catch misses. Writing a task is reviewing it, so leaving the stamp off pushed every fresh task to the top of the next review batch to be re-derived by someone with less context than its author had. Tonight's sweep sent the staleness count from 13 to 22 while the list got more accurate.

1 files changed, 50 insertions, 0 deletions

diff --git a/claude-rules/todo-format.md b/claude-rules/todo-format.md
index a4ffc34..e6a34e9 100644
--- a/claude-rules/todo-format.md
+++ b/claude-rules/todo-format.md
@@ -5,6 +5,56 @@ Applies to: `**/*.org` (org-mode todo and inbox files)
 How task entries are structured in org-mode todo files (`todo.org`,
 `inbox.org`, any GTD-style org file). Same shape across every project.
 
+## Stamp `:LAST_REVIEWED:` when you create the task, not a cycle later
+
+Every task filed at `**` with a priority cookie carries a `:LAST_REVIEWED:`
+property from the moment it's written:
+
+```
+** TODO [#B] Terse topic phrase :tag:
+:PROPERTIES:
+:LAST_REVIEWED: 2026-07-23
+:END:
+Body.
+```
+
+Use today's date, from `date +%F`. The org-native `[YYYY-MM-DD Day]` form is
+equally valid; both parse.
+
+**Why.** Writing a task *is* reviewing it. Whoever files it has just written
+the body, chosen the wording, and graded the priority against the scheme — that
+is the same judgment `task-review` applies, made with better context, because
+the reason for the task is still in the room. Leaving the stamp off asserts the
+opposite: `task-review-staleness.sh` sorts a missing property first, as
+never-reviewed, so a task filed today arrives at the top of tomorrow's review
+batch and gets "reviewed" by someone re-deriving what its author knew a day
+earlier. That is ceremony, and ceremony teaches people to click through the
+real thing.
+
+The concrete case: the 2026-07-23 sweep filed eight tasks in one night. Every
+one landed unstamped, and the staleness count went 13 → 22 while the list got
+*more* accurate, not less. The number stopped measuring drift and started
+measuring recent activity.
+
+**This applies to every path that files a task**, not just the inbox: inbox
+filing, triage intake, spec decomposition, task audit, a bug found mid-session,
+a task you write by hand. If you wrote a task body today, stamp it today.
+
+**What it does not do.** The stamp never means "correct forever" — it means
+"a person judged this on that date." A task filed today still enters the
+review rotation on the normal cycle; it just enters it on the *next* cycle
+rather than immediately. And it's a claim about a real event, so don't stamp
+a task you didn't actually consider: a bulk import of someone else's list
+is genuinely unreviewed, and stamping it would convert "nobody has read
+these" into a false "reviewed today."
+
+**Enforcement.** `lint-org.el`'s `task-missing-last-reviewed` checker flags any
+open `**` task with a priority cookie and no stamp, scoped to exactly the
+headings `task-review-staleness.sh` selects, so the checker and the staleness
+count never disagree. It's judgment-only and never auto-fixes: nothing can know
+when an unstamped task was actually last considered, and writing today's date
+onto an old one would destroy the very signal the property carries.
+
 ## Priority and Tag Scheme Header
 
 Every project's `todo.org` opens with a top-level section named