generateStreamingResponse retrieves docs only, so the streaming path will regress code search

Found by the review of PR #242 (Phase 2, code search).

AIPipeline.generateSupportResponse now retrieves over docs and source. generateStreamingResponse still calls searchDocs only.

So the same question answered on the streaming path gets docs-only retrieval, while the prompt it runs under (GROUNDING_RULES, updated in #242) tells the model that source code may be present and that documentation silence is not evidence a feature is missing. The model is invited to reason about evidence the streaming path never fetched.

Latent rather than live: nothing in production reaches it. handlers/ai-response.ts and apps/web/src/app/api/qa/route.ts both call generateSupportResponse. But it will silently regress the #242 fix the moment anyone streams, and "no production caller" is exactly why the streaming path has drifted before — see #237 (no empty-response guard, raw provider error yielded as content) and #146 (streaming still reads the pre-#143 groundedness signal).

Three issues now describe the same underlying thing: generateStreamingResponse is a second copy of the pipeline that nobody exercises. Worth deciding whether to bring it to parity or delete it until there is a caller, rather than fixing each divergence as it is spotted.

Start with AIPipeline.generateStreamingResponse and compare it with generateSupportResponse, especially the searchDocs call; review handlers/ai-response.ts, apps/web/src/app/api/qa/route.ts, and PR #242 with issues #237 and #146. Decide whether streaming should be brought to parity or removed while uncalled, then verify the chosen path no longer leaves retrieval and grounding behavior divergent.