Add tj-observer skill — detect whether a task was a good Thunderjar candidate

Build the first of the two mechanisms flagged as missing in [docs/regular-usage-workflow.md](docs/regular-usage-workflow.md#two-mechanisms-still-needed):

> Something needs to notice "this session just ended in success, is this a good Thunderjar candidate?" and prompt the user to walk through turning it into a task.

## Scope to nail down
- Skill invoked by the user in the moment vs. a hook that proactively watches every turn and nudges — not yet decided per the doc.
- What "good candidate" detection actually checks — maps to the Scenario 1/2/3 framework in the workflow doc (clean one-shot / one-shot-with-correction / needs-ongoing-steering). Scenario 3 should be explicitly rejected, not silently ignored.
- Output: presumably walks the user toward the `A..D` diff → measurements mining process (see [[tj-test-case skill]] below) rather than doing the mining itself.

Start with docs/regular-usage-workflow.md, especially the “two mechanisms still needed” section and the Scenario 1/2/3 framework. Resolve whether this is a user-invoked skill or a proactive hook, define candidate detection and explicit rejection of Scenario 3, then connect the output to the A..D diff and measurements mining process described there.

Written by the indexing model from the issue text.