fix(rig-gemini-grpc): populate FunctionDeclaration.parameters from ToolDefinition

[abhicris]

Why

create_grpc_request builds proto::FunctionDeclaration from a rig_core::completion::ToolDefinition, but only forwards name and description. The ToolDefinition.parameters JSON schema is silently dropped, so Gemini receives every tool with no argument shape. In practice this turns every tool call into an argument-less invocation, which surfaces as the model either omitting required args or guessing.

The proto already exposes the destination field:

message FunctionDeclaration {
  string name        = 1;
  string description = 2;
  Schema parameters  = 3;   // ← never populated
  ...
}

Fixes #1710. Same field present in rig-gemini-grpc 0.2.0 through the current 0.2.5.

What

Add a small JSON Schema → proto::Schema converter (json_value_to_proto_schema / tool_parameters_to_proto_schema) local to rig-gemini-grpc::completion, and pipe tool.parameters through it where the FunctionDeclaration is built.

Conventions chosen to match the existing rig-core::providers::gemini implementation:

• The empty-object schema {"type": "object", "properties": {}} (the default ToolDefinition.parameters for argument-less tools) is mapped to None rather than a vacuous Schema, so we don't emit properties: {} to the API for tools that genuinely take no arguments.
• Null input also maps to None.
• type/format/description/nullable/enum/items/properties/required are mapped 1:1; recursion handles nested arrays/objects.
• The converter lives inside this crate (no rig-core schema-helper leak) and uses only serde_json + the generated proto types, so it doesn't widen the public API.

How validated

cargo test  -p rig-gemini-grpc --lib
  running 10 tests
  ...
  test result: ok. 10 passed; 0 failed; 0 ignored

cargo clippy -p rig-gemini-grpc --all-targets
  Finished `dev` profile [unoptimized + debuginfo] target(s)
  (no warnings, no errors)

cargo doc    -p rig-gemini-grpc --no-deps
  Generated target/doc/rig_gemini_grpc/index.html

Five new unit tests in crates/rig-gemini-grpc/src/completion.rs:

• tool_params_empty_object_maps_to_none — preserves the existing "no-args" convention.
• tool_params_null_maps_to_none — defensive coverage for a Null parameters value.
• tool_params_object_with_scalar_properties_round_trips — checks type, required, nested properties types and descriptions.
• tool_params_array_with_typed_items — recursive items handling.
• tool_params_enum_strings_preserved — string enum round-trip.
• create_grpc_request_populates_tool_parameters — end-to-end regression test that drives create_grpc_request with a ToolDefinition and asserts FunctionDeclaration.parameters is populated with the expected typed schema. This is the test that would have caught the original bug.

Out of scope

• FunctionDeclaration.parameters_json_schema (field 6) — Gemini's newer JSON-Schema-passthrough field. The typed Schema path is what rig-core::providers::gemini uses today, so this PR stays on that path for consistency. A follow-up could add an opt-in to send the raw JSON schema as parameters_json_schema for callers that want to bypass the type mapping.
• FunctionDeclaration.response (field 4) — tool response schemas. Not currently carried on ToolDefinition; out of scope here.
• Composition (anyOf / oneOf / allOf) — rig-core::providers::gemini has additional flattening for these; the gRPC path can follow if real-world tools start tripping it, but bug(rig-gemini-grpc): tool parameter schemas dropped from FunctionDeclaration #1710's reproduction doesn't require it.