feat: Expose session ttl/expire_time through the api_server REST create-session endpoint

[ItsMacto]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Addresses: Expose session ttl / expire_time through the api_server REST layer and get_fast_api_app #6342 (implements option 1 from the issue, as proposed in this comment; option 2, a construction-time default TTL that would also cover --auto_create_session, is left as a follow-up so this PR stays small)

2. Or, if no issue exists, describe the change:

Problem:
VertexAiSessionService.create_session(**kwargs) supports ttl and expire_time, but deployments that serve ADK through adk api_server / get_fast_api_app cannot use them. The REST create-session endpoint only accepts state / session_id / events and forwards nothing else, so there is no way to create an expiring session over HTTP without patching private internals.

Solution:
Add optional expire_time and ttl fields to CreateSessionRequest and forward them to the session service, with the following behavior:

• Values are passed through verbatim as strings (RFC 3339 timestamp for expire_time, duration like "7200s" for ttl), matching the documented kwarg usage. The Vertex API stays the authority on value formats.
• The two fields are mutually exclusive. A request setting both fails validation (422) with the same message VertexAiSessionService itself raises for that case.
• The fields are only forwarded when actually set, so existing callers and backends see a byte-identical service call.
• If expiration is requested but the configured session service does not accept expiration kwargs (in-memory, database), the endpoint returns 400 with a clear message instead of silently ignoring the request. Support is detected by checking whether the service's create_session accepts **kwargs, so custom services registered through the service registry work without the server having to know about them.
• The deprecated POST .../sessions/{session_id} endpoint is intentionally unchanged.

I kept the REST surface to an explicit whitelist of the two expiration fields rather than an open kwargs pass-through. The underlying Vertex config also accepts keys like http_options and wait_for_completion that should not be reachable by HTTP clients, and named fields keep the OpenAPI schema meaningful. Safe user-facing keys such as display_name and labels could be added the same way later if there is interest.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

Five tests added to tests/unittests/cli/test_fast_api.py, using a small InMemorySessionService subclass that accepts and records expiration kwargs:

• expireTime is forwarded to a supporting session service as expire_time.
• ttl is forwarded as ttl.
• Setting both ttl and expireTime returns 422.
• Requesting ttl against a plain InMemorySessionService returns 400 with the not-supported message.
• Existing create-session tests cover the unchanged default path (no expiration fields, in-memory backend).

$ pytest tests/unittests/cli/test_fast_api.py -q
90 passed

pyink --check and isort --check-only are clean on both touched files, and mypy reports no new errors on api_server.py compared to main.

Manual End-to-End (E2E) Tests:

Not run against a live Agent Engine backend. The Vertex-side handling of ttl / expire_time is already covered by the existing VertexAiSessionService unit tests; this change only adds the REST plumbing in front of it, and the new unit tests exercise that seam directly through the FastAPI test client, including the 400 path.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

The mutual-exclusion error message intentionally reuses the exact wording from VertexAiSessionService.create_session so the two layers cannot drift apart.

[ItsMacto]

/gemini review