fix(extensions): forward empty extra_query and metadata in LiteLLM path

[weike-zhang]

Summary

LitellmModel drops an explicitly-configured empty extra_query / metadata dict before calling litellm.acompletion, because it uses falsy checks (if model_settings.extra_query:) instead of is not None checks. This diverges from the other two model paths:

• OpenAI (openai_chatcompletions.py): passes extra_query through as-is and forwards metadata unless it is None (_non_null_or_omit).
• AnyLLM (any_llm_model.py): switched to is not None checks in fix(extensions): nest extra_body on the any-llm chat path #4544.
• LiteLLM (litellm_model.py): still drops {}.

Change

Use is not None checks for extra_query and metadata in the LiteLLM chat path, matching #4544's handling in the AnyLLM path. Empty dicts are now forwarded instead of silently discarded.

Verification

• Added a regression test (test_empty_extra_query_and_metadata_are_forwarded) that mocks litellm.acompletion and asserts extra_query={} and metadata={} reach the provider. Confirmed it fails (KeyError: 'extra_query') before the fix and passes after.
• ruff check / ruff format --check clean on both touched files.
• Related LiteLLM tests pass (test_litellm_extra_body.py, test_litellm_content_filter.py, test_litellm_usage_requests.py — 16 passed).

[seratch]

Thanks for the contribution. I confirmed that LitellmModel currently omits empty extra_query and metadata mappings, but I could not find a supported behavior that changes when those empty mappings are passed to litellm.acompletion. ModelSettings resolution already accepts {} as an explicit override, so it can clear inherited values; after that, omitting the empty mapping produces the same request outcome. The new test only locks the adapter-to-LiteLLM call shape, while #4544's empty-mapping assertions were incidental to its extra_body fix and do not establish a separate need here.

I am going to close this PR. If there is a concrete LiteLLM provider or supported callback for which omission and {} produce different user-visible behavior, please share that scenario and we can reconsider the narrower requirement.