fix(retrieval): widen the fetch when wide_search_top_k is unset

[chiruu12]

Description

CompletionRetriever never widened its vector fetch when personalization weights were active, so
preference weights could only reorder the chunks top_k already returned. The comment above the
call says the opposite is the point: personalization has to change which chunks make the cut, not
just their order.

The search path reads the value with kwargs.get("wide_search_top_k") and no default, so None
reaches the retriever and the signature default of 100 never applies.
GraphCompletionRetriever normalizes that; CompletionRetriever, the one completion retriever that
does not subclass it, did not. max(self.top_k, None or 0) is top_k, so the widening disappeared.

One line, mirroring graph_completion_retriever.py:75 exactly, same default:

self.wide_search_top_k = 100 if wide_search_top_k is None else wide_search_top_k

Introduced in #4611, which changed the producer and normalized the graph retriever in the same diff
but not this one.

Test

test_unset_wide_search_top_k_still_widens_the_fetch in the existing personalization suite,
constructing the retriever the way the search path does rather than with an explicit value. That is
the gap the existing cases left: all of them pass wide_search_top_k=WIDE_SEARCH_TOP_K, so None
was never exercised.

Fails on main (limit is 2), passes with the fix (limit is 100).

Validation

pytest cognee/tests/unit/modules/user_preferences/test_rag_personalization.py   13 passed
pytest cognee/tests/unit/modules/retrieval cognee/tests/unit/modules/user_preferences
                                                                                10 failed, 634 passed
ruff check                                                                      All checks passed
ruff format --check                                                             2 files already formatted

The 10 failures are pre-existing. I ran the same selection on origin/main with the change stashed
and diffed the failure lists: identical, same 10 names, and the only difference is the one test this
PR adds.

Closes #4650

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[chiruu12]

Retargeted back to main.

I moved this to dev earlier because that is where most merges land. That was wrong for this change: the module it touches is not on dev. cognee/tests/unit/modules/user_preferences/ does not exist there, and completion_retriever.py has no wide_search_top_k at all.

The two branches also disagree about the bug. On dev the call site is kwargs.get("wide_search_top_k", 100), so None never reaches a retriever. On main it is kwargs.get("wide_search_top_k") with no default (get_search_type_retriever_instance.py:85), which is what makes max(self.top_k, self.wide_search_top_k or 0) collapse to top_k.

So this belongs on main, and it conflicts on dev for the same reason it does not apply there. Worth flagging that whenever the two reconcile, main's call site still needs the default or this normalization.