feat(adk): pass telemetry attributes through toolbox-adk

[AjmeraParth132]

Background

toolbox-core now supports TelemetryAttributes and sends them through MCP _meta for extended telemetry / SQLCommenter (#632, #634). toolbox-adk did not expose that flow, so ADK users could not attach model, user ID, or agent ID metadata when invoking Toolbox tools through ToolboxToolset.

This PR adds ADK pass-through support for telemetry attributes.

Changes

• Add telemetry_attributes to ToolboxToolset.
• Pass telemetry_attributes into each wrapped ToolboxTool.
• Add telemetry_attributes support to ToolboxTool.
• Support static TelemetryAttributes and sync/async callbacks.
• Support callbacks that accept ADK ToolContext, matching the existing auth token getter
  pattern from feat(adk): Support ToolContext for auth_token_getters in toolbox-adk #579.
• Resolve telemetry attributes per invocation and apply them to a derived core tool via
  add_telemetry_attributes(...).
• Avoid mutating the shared wrapped core tool so context-specific user/agent metadata does not
  leak between invocations.
• Preserve telemetry configuration when bind_params(...) returns a new ADK wrapper.
• Add regression coverage for user identity cleanup when telemetry resolution fails.

Related

• Builds on Send client telemetry attributes in _meta for Extended Telemetry and SQLCommenter #632 / feat(toolbox_core): enable telemetry_attribute for SQLCommenter #634.
• Follows the ADK ToolContext callback pattern from feat(adk): Support ToolContext for auth_token_getters in toolbox-adk #579.

[anubhav756]

/gcbrun

[anubhav756]

/gcbrun

[anubhav756]

/gcbrun

[anubhav756]

As discussed let's add documentation to the docsite repo following this. I'm also thinking if we can optionally add some integration tests as well?

[anubhav756]

optional: Is it by any chance still possible to pass a function with default arguments?

def get_telemetry(ctx: ToolContext, default_model: str = "gemini-3.5-flash") -> TelemetryAttributes:
    return TelemetryAttributes(llm_model=default_model, ...)

If so then len(sig.parameters) will be 2 and it falls through calling attributes() with 0 arguments and may complain about missing 1 required positional argument (ctx).

If it makes sense then should we also determine whether the function can accept 1 positional argument by checking parameter kinds and required parameters, or by inspecting positional parameters?

[anubhav756]

optional: Curious what if the callable wants to resolve a None for user id for instance? Do we handle an empty string for that in this object or do we want to support Optional[TelemetryAttributes] as a return type of the callable? I'm fine with the former.

[anubhav756]

/gcbrun

[anubhav756]

/gcbrun

[twishabansal]

Approving to unblock multi approvers CI check