Expose session ttl / expire_time through the api_server REST layer and get_fast_api_app

## Feature request

### Problem

v2.4.0 added `ttl` / `expire_time` support to `VertexAiSessionService.create_session(**kwargs)` (commit 49d4441). However, deployments that serve ADK through `get_fast_api_app` / `adk api_server` (e.g. a Cloud Run service with a web frontend that manages sessions over the REST endpoints) have **no way to set a session TTL at all**:

1. The REST create-session endpoints do not accept it. `POST /apps/{app_name}/users/{user_id}/sessions/{session_id}` accepts only `state`, and `POST /apps/{app_name}/users/{user_id}/sessions` accepts only `state` / `session_id` / `events` (`cli/api_server.py` — `create_session_with_id` / `create_session`). Neither forwards `ttl`/`expire_time` kwargs to the session service.
2. The `--auto_create_session` path creates sessions implicitly on `/run` without any TTL either.
3. There is no service-level default to fall back on: the `VertexAiSessionService` constructor takes no TTL parameter, `get_fast_api_app` accepts only a `session_service_uri` **string** (so a pre-configured/subclassed service instance cannot be injected), and the `agentengine://` URI has no TTL query parameter.

The net effect: REST-surface users cannot adopt the new TTL capability without monkey-patching private internals (the REST handler or the service factory).

### Proposed solution

Any of the following (in order of preference — they are complementary):

1. Accept optional `ttl` / `expire_time` fields in the REST create-session request bodies and forward them as kwargs to `session_service.create_session(...)`.
2. Support a **default TTL at service construction** — a `VertexAiSessionService` constructor kwarg, surfaced through a `session_service_uri` query parameter (e.g. `agentengine://?ttl=7200s`) and/or a `get_fast_api_app` parameter. This would also cover the `--auto_create_session` path, which has no request body to extend.

### Alternatives considered

- Subclassing `VertexAiSessionService` with a TTL default and registering it through the service registry (`services.py` in `agents_dir` + `get_service_registry().register_session_service(...)`, which `create_session_service_from_options` consults first): **works**, but it is per-deployment custom code — a private-ish factory each deployment must maintain and re-verify on every ADK bump. First-class `ttl` support in the REST body and/or a construction-time default would serve every integration without that custom surface.
- Patching the REST handler: private API, breaks on every upgrade.
- Setting expiration out-of-band via the Agent Engine Sessions API after creation: races with `--auto_create_session` and doubles the API surface the client must manage.

### Use case

Production agent on Cloud Run (`get_fast_api_app` + `session_service_uri="agentengine://"`), with a browser frontend that creates/loads sessions exclusively through the ADK REST endpoints. We want cost/privacy hygiene: sessions that auto-expire after a retention window instead of accumulating indefinitely in Agent Engine.

### Related

#4594 tracks the same gap on the `AdkApp.async_create_session` remote surface (Vertex AI SDK proxy path). This issue covers the `api_server`/`get_fast_api_app` REST surface — together they would make the v2.4.0 TTL capability reachable from every documented integration path.

### Environment

- google-adk: 2.4.0
- Python: 3.12