[api][plan][python] Use request-scoped metric groups for chat token metrics

[jlon]

What

• Capture the current action metric group when a chat request is initiated.
• Record delayed chat token metrics against that captured group instead of the mutable metric group on cached chat model resources.
• Add Java and Python regression coverage for resource metric-group rebinding.

Why

Cached resources can be rebound when another action retrieves the same resource before the original request records token usage. The delayed token metrics should stay under the action that initiated the request.

Closes #859.

Tests

• mvn -pl api -DskipITs -Dspotless.check.skip=true -Dcheckstyle.skip=true -Dtest=BaseChatModelSetupTokenMetricsTest test
• mvn -pl plan -am -DskipITs -Dspotless.check.skip=true -Dcheckstyle.skip=true -Dsurefire.failIfNoSpecifiedTests=false -Dtest=ChatModelActionTest,ChatModelActionRetryTest test
• bash -lc 'export PATH="$HOME/.local/bin:$PATH"; cd python && uv run --no-sync pytest flink_agents/api/chat_models/tests/test_token_metrics.py -q'
• bash -lc 'export PATH="$HOME/.local/bin:$PATH"; cd python && uv run --no-sync ruff format --check flink_agents/api/chat_models/chat_model.py flink_agents/api/chat_models/tests/test_token_metrics.py flink_agents/plan/actions/chat_model_action.py && uv run --no-sync ruff check flink_agents/api/chat_models/chat_model.py flink_agents/api/chat_models/tests/test_token_metrics.py flink_agents/plan/actions/chat_model_action.py'
• bash -lc 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64; export PATH="$JAVA_HOME/bin:$PATH"; mvn -pl api,plan -am spotless:check -Dspotless.skip=false -DskipTests -DskipITs -Dcheckstyle.skip=true'

[weiqingy]

The two languages now document slightly different contracts for the absent-group case: Java's 4-arg recordTokenMetrics treats a null group as "skip recording" (BaseChatModelSetup.java:135), while here metric_group is None falls back to self.metric_group — the live, possibly-rebound group. Every real call site passes a captured group (chat_model_action.py:334), so there's no impact on today's flow. The part I'm less sure about: a future caller passing None expecting Java parity would record under whatever action is currently bound — the #859 scenario again on the Python side, where Java would no-op instead. Is the asymmetry intentional? If the = None default is only there to keep the param optional for the test helper, dropping it so callers must pass the captured group would match Java's no-fallback contract; alternatively a one-line javadoc note that Java's null means skip would at least make each side self-documenting.