fix: tolerate empty toolNames on RemoteMCPServer refs

[reilly3000]

Summary

Fixes #1797. An Agent that references a RemoteMCPServer without an
explicit toolNames filter currently CrashLoops with a pydantic
ValidationError because the controller emits http_tools[*].tools = null
and the runtime rejects None. Whether toolNames is meant to be required
or optional is a call for maintainers — either way, the controller
shouldn't produce a config the runtime can't load.

This PR is intentionally defensive on both sides; happy to rework toward
a different direction (e.g. CRD validation making toolNames required, or
runtime-only fix) if maintainers prefer.

• Controller (Go): when toolNames is empty, expand to
  RemoteMCPServer.status.discoveredTools so the rendered config is
  explicit and observable in the agent's config.json Secret. Explicit
  toolNames continue to take precedence. Falls back to an empty array
  rather than null if status has no discovered tools yet.
• Runtime (Python): coerce tools: None → [] via a pydantic
  BeforeValidator on HttpMcpServerConfig / SseMcpServerConfig, so
  older controllers don't crash newer runtimes.

See #1797 for the full repro and root-cause analysis.

Test plan

• New Go translator regression test
  (Test_AdkApiTranslator_RemoteMCPServer_NoToolNames) asserts the
  rendered AgentConfig.HttpTools[0].Tools is non-nil, expanded from
  discovered tools, and serializes as a JSON array (not null).
• New Python pydantic test
  (test_http_tool_null_tools.py) covers tools: None, missing
  tools, and explicit tools: [...] for both Http and Sse
  variants.
• Full Go translator suite (go test ./core/internal/controller/translator/agent/...) — pass.
• Full Python kagent-adk unit suite (uv run pytest packages/kagent-adk/tests/unittests/) — pass (9 unrelated TLS e2e failures from missing local fixtures).
• Runtime-level e2e: invoked the actual kagent-adk static --filepath ... startup path (the same command the runtime container runs) against a config.json containing http_tools[*].tools = null.
  - Pre-fix: reproduces the exact ValidationError ... type=list_type, input_value=None and the process exits.
  - Post-fix: Application startup complete. / Uvicorn running on http://127.0.0.1:....
• In-cluster e2e against a real RemoteMCPServer: built an overlay image of the v0.9.1 runtime with only the patched types.py, swapped it in via controller.agentImage, and deployed against a live RemoteMCPServer that fronts ~50 federated MCP tools.
  - Pre-fix: a fresh Agent with no toolNames CrashLoops with the exact ValidationError ... input_value=None from the issue.
  - Post-fix: same Agent reaches Application startup complete / Uvicorn running on http://0.0.0.0:8080 and serves 200 on /.well-known/agent-card.json.
• Controller-side e2e: built an overlay image of the v0.9.1 controller with only the patched binary, swapped it in via controller.image, and applied a fresh Agent referencing the same RemoteMCPServer (23 discoveredTools) with no toolNames specified.
  - Resulting agent pod reaches Application startup complete / Uvicorn running cleanly.

Open questions for reviewers

1. Is toolNames intended to be required, or optional with omission
   meaning "all discovered tools"? If the former, this PR can be reduced
   to CRD validation + a clear admission error.
2. Is the controller-side expansion to discoveredTools desirable for
   observability, or would you prefer the controller emit [] (or
   omit the field entirely) and have the runtime handle the "all tools"
   semantics on its own?

Notes

• Same nil-slice → JSON null defect existed for sse_tools[*].tools;
  fixed via the same resolveToolNames helper.
• Commit is DCO-signed.

[reilly3000]

Hi folks, I hate to be the ai slop PR guy, but ran into this issue and thought others may make the same assumption as well. I have a couple tweaks inbound before I raise it for review.