fix(tracing): record zero top_k / chunk_size in update_retriever_span - #3406

What

update_retriever_span(...) guarded top_k and chunk_size on truthiness, so a caller that legitimately reports top_k=0 (or chunk_size=0) silently gets the value dropped instead of recorded on the span.

This changes both guards to is not None, which is what the signature already implies: None is the "not provided" marker, so 0 should be a recordable value.

Why

next_retriever_span(...) already persists zeros for these fields through _drop_none, so the two entry points disagree — the same trace built through the update path loses data that the constructor path keeps.

How I checked

Added tests/test_core/test_tracing/test_update_functions/test_update_retriever_span_zero_values.py:

• test_zero_top_k_and_chunk_size_are_recorded — fails on current main with AssertionError: assert None == 0, passes with the guard change.
• test_omitted_fields_are_left_untouched — pins the existing behavior that omitted (None) fields must not overwrite values already on the span.

Measured on origin/main (a200ecede) with the fix reverted vs applied:

# reverted, only the new file
1 failed, 1 passed   (test_zero_top_k_and_chunk_size_are_recorded -> assert None == 0)
# applied
tests/test_core/test_tracing/test_update_functions/ -> 18 passed in 2.25s

embedder keeps its truthiness guard on purpose — an empty embedder name carries no information, unlike a zero count.

CI note

This branch has 11/13 checks green; the two red test shards fail on tests that are already red on main (a200ecede) with the same node id and the same message:

• tests/test_core/test_sqlite_store.py::TestTestRunManagerIntegration::test_storage_failure_is_a_warning_not_an_error — AssertionError: assert 'disk I/O error' in 'Warning: fa…' (the rich 80-column wrap of the saved-run path in deepeval/test_run/test_run.py).
• tests/test_metrics/test_eval_mode_metrics.py::test_hybrid_jev_takes_the_decisions[sync-MultiTurnMCPUse] — AttributeError: 'CallToolResult' object has no attribute 'structuredContent'.

Both look unrelated to this diff, and #3316 / #3373 appear to already target them. Because the core shard runs with --maxfail=1, it stops at the sqlite failure before reaching tests/test_core/test_tracing/, so the tests added here don't show up in that log; locally this whole directory is green (18 passed).