fix(configurable): prevent path traversal in AgentTool config_path resolution - #1407

Summary

ConfigAgentUtils.resolveSubAgentFromConfigPath() accepted absolute config_path values unconditionally, and for relative values only logged a warning when the resolved path escaped the agent's own base directory -- it did not block the load:

if (Path.of(configPath).isAbsolute()) {
  subAgentConfigPath = Path.of(configPath);   // accepted unconditionally
} else {
  subAgentConfigPath = configDir.resolve(configPath);
}
Path resolvedConfigPath = subAgentConfigPath.normalize().toAbsolutePath();
Path baseDir = configDir.normalize().toAbsolutePath();
if (!resolvedConfigPath.startsWith(baseDir)) {
  logger.warn(...);   // <-- warning only, no return/throw
}
if (!Files.exists(subAgentConfigPath)) { ... }
return fromConfig(subAgentConfigPath.toString());   // proceeds regardless

This is the same vulnerability class already hard-fixed with a breaking change in both other language ports:

• adk-go: google/adk-go@604dd63 ("BREAKING: an absolute config_path is no longer accepted")
• adk-python: commit 171ae9e

This port (issue #1218) had instead chosen a warn-only deprecation, leaving the traversal fully exploitable today: a config_path such as ../../another_tenant/secret_agent.yaml or an absolute path is loaded and parsed as a full agent configuration, with only a log line noting the escape.

Reachability

config_path is a field in a subagent reference within an agent's own YAML config (sub_agents: - config_path: ...). In any deployment where different trust domains' agent configs are hosted under a shared root (e.g. a multi-tenant agent-hosting platform, or any scenario where config content can be influenced by a less-trusted party), this allows reading and loading arbitrary files reachable by the process as agent configuration -- outside the intended per-agent containment directory.

Fix

• Reject absolute config_path values outright.
• Reject (rather than warn on) a resolved path that escapes the agent's base directory.
• Resolve symlinks on both sides where the paths exist (toRealPath(), falling back to the lexical path when the target doesn't yet exist, so a missing file is still reported as not-found rather than misclassified as a traversal) -- matching the symlink-escape protection in adk-go's second commit for the same fix.

Testing

• fromConfig_subAgentConfigPathTraversal_throwsConfigurationException -- the exact ../ escape case, confirmed rejected.
• fromConfig_subAgentAbsoluteConfigPath_throwsConfigurationException -- the absolute-path case, confirmed rejected.
• The existing fromConfig_withSubAgents_createsHierarchy test (a legitimate in-directory subagent reference) is unmodified and continues to pass, confirming no regression.

Verification performed

Maven Central is not reachable in the environment I used to develop this fix, so I could not run mvn test locally. I instead dynamically confirmed both the vulnerability and the fix using a faithful, line-for-line transcription of the real method (standard JDK only, no external dependencies needed to exercise this specific logic):

• Before the fix: a crafted ../secret_dir/victim_secret.yaml path logged the deprecation warning, then proceeded to read the target file's full content regardless.
• After the fix: the same input is rejected with "Path traversal detected: ..."; an absolute path is rejected with "Absolute paths are not allowed..."; a legitimate in-directory reference still succeeds.