fix(backend/copilot): disallow ScheduleWakeup SDK built-in (#13187)

## Why

The Claude Agent SDK CLI ships a `ScheduleWakeup` built-in that is only
functional inside Claude Code's `/loop` dynamic-mode runtime. Our
copilot/autopilot turns have no such runtime — each turn runs to
completion on a stateless `copilot_executor` worker. When invoked there,
`ScheduleWakeup`'s handler returns `{"scheduledFor": 0, "wasClamped":
false}`
and nothing is actually scheduled.

We were not registering this tool ourselves, but it was also absent from
`SDK_DISALLOWED_TOOLS`, so the SDK exposed it to the model. The model
would call it, treat the success-shaped response as confirmation that a
follow-up was queued, and end the turn — leaving the user with a silent
session that promised work that will never happen.

## What

Add `"ScheduleWakeup"` to `SDK_DISALLOWED_TOOLS`. `BLOCKED_TOOLS`
already
unpacks `SDK_DISALLOWED_TOOLS`, so the security-hook deny path
automatically covers any attempt to bypass the SDK filter.

Test added asserting `ScheduleWakeup` is in the list.

## How

`SDK_DISALLOWED_TOOLS` feeds `ClaudeAgentOptions.disallowed_tools` via
`get_sdk_disallowed_tools()`. The SDK strips disallowed tools from the
advertisement the model sees, so the model never gets the opportunity to
call it. The defence-in-depth security hook (`_validate_tool_access` in
`security_hooks.py`) rejects any sneaky call attempts via
`BLOCKED_TOOLS`.

If we want a real "do this in 20 minutes" feature in copilot, the right
shape is a new MCP tool backed by the scheduler that enqueues a
`copilot_turn_schedule` row and fires `enqueue_copilot_turn` at the
target time. That's out of scope here — this PR just stops the
misleading
no-op.

## Changes

- `tool_adapter.py`: add `"ScheduleWakeup"` to `SDK_DISALLOWED_TOOLS`
with a
  one-line WHY comment.
- `tool_adapter_test.py`: assert membership.

## Checklist

- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules