fix(retrieval): reject months/weeks/years quantity phrases in version extraction

[detail-app]

Detail bug report: View on Detail

Bug

QueryVersionExtractor.extractVersionNumbers parses learner queries for Java release versions. The EXPLICIT_QUANTITY_SUFFIX_PATTERN (added in cacf649) rejects Java <N> <unit> of practice quantity phrases, but its noun list enumerated only days/hours/minutes/seconds/times/line and omitted the most common time units — months, weeks, years. A phrase like switched to Java 6 months ago was misread as a request for Java 6, leaking the spurious token ["6"] into every consumer:

• Chat retrieval — the configured default Java 25 scope was swapped for Java 21 (spurious "6" resolved nearest-higher).
• Guided-learning retrieval — the lesson's dev-java tutorial supplement was dropped, narrowing retrieved supplements to Java 21 API-only.
• Source-record headers — a requestedVersions="6" / adjacent-same-family header was injected for Java docs, byte-for-byte identical to the designed out-of-range path.

Fix

Add weeks?|months?|years? to EXPLICIT_QUANTITY_SUFFIX_PATTERN in QueryVersionExtractor — a one-line alternation extension; no production call-site changes.

Known trade-off (unchanged in kind, not a regression-in-kind): the new nouns inherit the same word-hyphen false-positive class days? already exhibits — Java 25 year-ahead roadmap / month-release cadence / week-long sprint now also suppress 25, matching the pre-existing Java 25 day-release cadence behavior. A more selective suffix pattern would narrow rejection for the existing entries too and is out of scope here.

Closes #245

Testing

• Direct unit tests (QueryVersionExtractorTest): extended the quantity-noun loop to cover week/weeks/month/months/year/years; added rejectsTemporalQuantityPhrasingsWhereJavaPrecedesTheDigits (the bug-case canary: switched to Java 6 months ago, Java 5 years of experience, been on Java 8 months, … → all []); added extractsReleaseRequestsAdjacentToNonQuantitySuffixWords to guard the \b boundary so Java 25 monthly/yearly/weekly … still extract 25 (prevents over-suppression of adverbial forms).
• Routine checks all pass: compile, full ./gradlew test, spotlessCheck, PMD, SpotBugs, and the full pre-push gate make format && make lint && make build && make test (1169 JVM tests across 140 classes, 0 failures; 14 shell contract scripts pass). To unblock make lint I installed the two missing tools the Makefile requires (ast-grep via npm, ruby via apt).
• Consumer-path verification (run via probes against the real RetrievalService, ChatService, and GuidedLearningService with only downstream search/LLM mocks, but not committed as tests — the fix is in a pure utility whose return value pins the contract, and existing days-based consumer tests already exercise these paths): confirmed the chat path resolves switched to Java 6 months ago to the configured-default Java 25 scope (not Java 21), the guided-learning path keeps the lesson's dev-java + java/java25-complete doc-set, and the chat header path emits no requestedVersions="6" / adjacent-same-family header.
• End-to-end runtime smoke could not be run: the backend boot requires credentials for the private shared LLM gateway (https://api.llm-gateway.iocloudhost.net/v1) and a pre-indexed corpus, neither available in this environment. I started Qdrant 1.18.3 and walked the boot through to the embedding-gateway call, which rejected the dummy key with 401 Invalid API Key. The bug-relevant behavior (version parsing and scope resolution) runs before any Qdrant search or LLM call and is covered by the unit tests above.

---

Automatic Fixes PRs can be configured here.