[DOCS] ScheduleWakeup tool description claims "5-minute TTL" but subscription main sessions use 1-hour TTL

Description:

The built-in description of the ScheduleWakeup tool states: "The Anthropic prompt cache has a 5-minute TTL. Sleeping past 300 seconds means the next wake-up reads your full conversation context uncached" — and derives pacing guidance from it (e.g. "Under 5 minutes (60s–270s): cache stays warm").

Expected: Per the official docs (prompt-caching → Cache lifetime), on a Claude subscription the main session requests the one-hour TTL automatically. The tool description should reflect this (or state that TTL depends on authentication).

Actual: The description unconditionally states 5 minutes.

Evidence: On my machine (subscription, desktop app, no ENABLE_PROMPT_CACHING_1H / FORCE_PROMPT_CACHING_5M set), all cache_creation entries in session transcripts land in the ephemeral_1h_input_tokens bucket (371/371 records checked; ephemeral_5m_input_tokens = 0).

Impact: The stale description misleads the model into designing wake-up/keep-alive cadences around a 5-minute window. In my case the agent scheduled keep-alive beats every ~220s to "keep the cache warm" — pure wasted quota, since the cache had a 1-hour lifetime. Given the TTL regression history (#46829) and the env-var doc gaps (#48082), tool-description accuracy matters here: agents act on tool descriptions directly.

Suggestion: Make the description authentication-aware ("5-minute TTL on API keys; 1-hour on subscription main sessions; subagents always 5m"), or point to the prompt-caching doc instead of hardcoding a number.

Related: #48082, #46829