fix(secret-resolver): update secret resolver logic when set SERVICE_BINDING_ROOT

[cassiofariasmachado]

Description

Fixes the secret resolver so that applications deployed in environments following the servicebinding.io spec can load service bindings without manual configuration.

Problem: When SERVICE_BINDING_ROOT is set, the resolver looked for secrets at $ROOT/<module>/<instance>/<field> (three levels). The servicebinding.io spec mandates a flat two-level layout: $ROOT/<binding-name>/<field>. This caused create_client() to fail with a path-not-found error for any binding mounted under the flat convention, including the Agent Memory service.

Fix: When SERVICE_BINDING_ROOT is explicitly set, the resolver now tries the flat path $ROOT/<module>/<field> first (servicebinding.io spec), then falls back to the legacy three-level path $ROOT/<module>/<instance>/<field> (existing AppFND convention), and finally falls back to environment variables. When SERVICE_BINDING_ROOT is not set, only the legacy path is tried — no behaviour change for existing deployments.

The fix is applied centrally in read_from_mount_and_fallback_to_env_var, so all SDK modules (Agent Memory, Audit Log, Destination, Object Store, DMS) benefit automatically.

The internal refactor extracts _load_from_path(secret_dir, target) from _load_from_mount so both code paths share identical file-reading logic with no duplication.

Related Issue

N/A

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Code refactoring
• Dependency update

How to Test

1. Deploy an application that uses create_client() (e.g. Agent Memory) in an environment where
   SERVICE_BINDING_ROOT is set and the binding is mounted flat at
   $SERVICE_BINDING_ROOT/<binding-name>/<field>.
2. Verify the client initialises without AgentMemoryConfigError and can make requests.

To test locally with unit tests:

uv run pytest tests/core/unit/secret_resolver/ -v

Key new test cases:

• test_service_binding_root_flat_path_success — flat path is tried first when SERVICE_BINDING_ROOT is set
• test_service_binding_root_flat_fails_falls_back_to_module_instance — graceful fallback to legacy layout when flat files are absent
• Updated test_service_binding_root_overrides_base_mount — verifies the flat path is now the first attempt

Checklist

• I have read the Contributing Guidelines
• I have verified that my changes solve the issue
• I have added/updated automated tests to cover my changes
• All tests pass locally
• I have verified that my code follows the Code Guidelines
• I have updated documentation (if applicable)
• I have added type hints for all public APIs
• My code does not contain sensitive information (credentials, tokens, etc.)
• I have followed Conventional Commits for commit messages

Additional Notes

The fallback is safe for environments that set SERVICE_BINDING_ROOT but use the older three-level layout: the flat attempt finds the parent directory but fails to read the field files (which live in the <instance>/ subdirectory), so the resolver silently falls through to the legacy path.