[plan] Extract ResourceCache and PythonResourceBridge from AgentPlan

[weiqingy]

Linked issue: #547

Purpose of change

AgentPlan (624 lines) mixes plan definition, resource caching/resolution, Python bridge wiring, and serialization.
This PR extracts two classes to separate concerns:

• ResourceCache — lazy resource resolution, caching, and cleanup. Created by the operator in open(), owned by
  the operator lifecycle.
• PythonResourceBridge — static discoverPythonMCPResources() for Python MCP tool/prompt discovery. Called
  during operator init.

After extraction, AgentPlan becomes immutable after construction (~490 lines, down from 624). The removed public
methods are getResource(), close(), and setPythonResourceAdapter().

Tests

• mvn test -pl plan — all plan module tests pass
• mvn test -pl runtime — all runtime module tests pass
• ./tools/lint.sh -c — formatting check passed
• ./tools/ut.sh -j — full Java test suite passed

API

Yes. Three public methods removed from AgentPlan:

• getResource(String, ResourceType) — replaced by ResourceCache.getResource()
• close() — replaced by ResourceCache.close()
• setPythonResourceAdapter(PythonResourceAdapter) — replaced by PythonResourceBridge.discoverPythonMCPResources()

Documentation

• doc-needed
• doc-not-needed
• doc-included

[weiqingy]

Both CI failures are unrelated to our changes:

1. it-python [flink-2.2] — Ollama download returned HTTP 404. This is a transient infrastructure issue — the Ollama release artifact was temporarily unavailable. Nothing to fix on our side.
2. cross-language — Py4JError / Py4JNetworkError in the cross-language e2e tests. The Java gateway crashed during test_java_chat_model_integration and subsequent tests couldn't connect. Our PR only touches plan/ and runtime/ Java code — it doesn't affect the Python-Java bridge or cross-language e2e test infrastructure.

[wenjin272]

Thanks for your work @weiqingy and I think the separation makes sense.

Besides, I think we should also apply this separation in the python side. If possible, could you implement this in this PR?

[wenjin272]

Should we use ConcurrentHashMap here? For task submit by ctx.durableExecuteAsync may read/write this hashmap parallel.