learn: retrospective learnings - #908

🔵 Low — This new 2026-09-28 section is a near-duplicate of the immediately-preceding 2026-09-24 section: both cover the same PR #947 fix to RedactUrlQueryParamsFilter.filter in src/databricks/sql/__init__.py, and both carry the identical since 2026-09-18T17:27:19Z window start. The retrospective window evidently did not advance (both say "since 2026-09-18T17:27:19Z"), so the same learning was re-emitted with only slightly reworded Context/Rule text.

The log's own convention comment says each daily run appends "one dated section of 0..N learnings" — a genuinely-new run that surfaced no new source PR should append 0 learnings rather than restate a prior one. As written, a future reader mining this log for durable lessons hits the same record.args-mutation rule twice back-to-back, and the duplicated since timestamp obscures which retrospective actually produced it. Consider dropping this section (or, if a new run genuinely occurred with nothing new, appending an empty-dated section) so the log doesn't accumulate restated duplicates.

🔵 Low — The same PR #947 RedactUrlQueryParamsFilter.filter learning is emitted three times in a row, in the 2026-09-24, 2026-09-28, and 2026-10-07 sections, each phrased slightly differently but conveying the identical rule (handle record.args as None/tuple/dict, test the dict branch).

Tellingly, all three sections carry the same learnings since 2026-09-18T17:27:19Z watermark, which suggests the retrospective's since-cursor isn't advancing after each run, so it keeps re-distilling the same merged PR into a fresh dated section. Each subsequent run will likely append yet another copy. Worth checking the cursor-advance logic in the retrospective job (databricks_bot_engine.engineer_bot.retrospective) so the window base moves forward once a learning is recorded; otherwise the rolling log accretes duplicates until merge.