changelog-bot's Jev trick: pick the Why, don't write it

The problem @nyaomaru ran into is that an LLM handed a pull request and asked "Why was this change made?" will happily summarize, paraphrase, combine sentences, and infer reasons that were never stated. For a changelog, that is the wrong kind of help. The pivot was to reclassify the task: not "How can AI write a good reason?" but "How can we find evidence that the reason already exists?" That reframing splits the work between deterministic code, which locates and normalizes candidate evidence, Jev, which evaluates it, and a renderer, which formats it.

This fits the project's broader v1 direction, which the author calls "deterministic-first": a complete changelog should be produced even if the AI is disabled or fails. AI enriches the changelog rather than owning it. The WHY engine is accordingly an optional enrichment step and does not generate the final Markdown itself, which stays with a single deterministic renderer. Phases 1 through 3 are already implemented, with the boundary between structured rendering and enrichment slated for further work.

The threshold question is being answered with measurement rather than intuition. The initial evaluation harness had 14 cases, mixing positives (where one candidate is clearly the reason) with negatives (where the correct answer is to select nothing), and after @johnnylemonny joined as a contributor, PR #212 expanded it to about 50 cases covering explicit rationale, implementation-only text, template noise, and multilingual pull requests. The author set one rule for the ground truth: it must be decided by humans independently of the current Jev threshold, so that labels are not simply whatever the model already scored highly.