feat(sessions): add secret: session state scope

[caohy1988]

Summary

Implements Phase 1 of the RFC in #5112: a new secret: prefix for session state keys that keeps sensitive data (tokens, credentials, API keys) in process memory only — never persisted to any storage backend and never logged by BigQuery Agent Analytics.

• State.SECRET_PREFIX ("secret:") added alongside existing app:, user:, temp: prefixes
• extract_state_delta() now excludes secret: keys from all persistence buckets
• Process-local cache on BaseSessionService with lifecycle helpers (_apply, _trim, _seed, _restore, _evict)
• All 4 session services updated: InMemory, Database, Sqlite, VertexAI — seed on create, restore on get, evict on delete
• BQAA redaction hardened: secret:* keys redacted; new _is_sensitive_json_string() detects credential-bearing JSON blobs
• Instruction template injection accepts secret: as a valid state prefix
• 32 new tests: unit tests for helpers + integration tests parametrized across InMemory/Database/Sqlite

Behavior

session = await session_service.create_session(
    app_name="app", user_id="user",
    state={"secret:api_key": "sk-xxx", "visible": "ok"},
)

# Available in process memory
session.state["secret:api_key"]  # → "sk-xxx"

# Survives get_session (restored from process cache)
restored = await session_service.get_session(...)
restored.state["secret:api_key"]  # → "sk-xxx"

# Never persisted — lost on process restart
# Never in event deltas — invisible to storage and analytics

Test plan

• 32 new tests in tests/unittests/sessions/test_secret_state.py
• 98 existing session service tests pass (no regressions)
• 187 existing BQAA plugin tests pass (no regressions)
• 14 existing instructions_utils tests pass (no regressions)
• Reviewer: verify secret keys do not appear in DB/Sqlite storage after append_event
• Reviewer: verify VertexAI session service strips secret keys before API call

Closes #5112

🤖 Generated with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[adk-bot]

Automated notice: a potentially related change has been submitted. Please verify no merge conflicts exist with incoming PRs. (ref: triage cross-check)