Fix pdb / breakpoint() hang in workflow code

[elidlocke]

What was changed

When debug_mode=True on the Worker (or TEMPORAL_DEBUG=1), breakpoint() inside workflow code now opens an interactive pdb prompt — including from a sandboxed workflow run under pytest. Four pieces:

• Inline dispatch on the main thread. Activations run on the asyncio main thread (scheduled via loop.call_soon to avoid nesting inside the dispatch task's __step()), so pdb's input() reaches the TTY.
• Targeted sandbox relaxation. breakpoint is removed from the sandbox's invalid builtins so the call can reach the worker hook. Nothing else is relaxed.
• Custom Pdb subclass. Drops into pdb at the workflow's own frame (not our indirection), suspends sandbox checks for the duration of each REPL interaction, and overrides q / Ctrl-D to continue the workflow instead of failing it with BdbQuit.
• Defensive sys.breakpointhook. Calling breakpoint() from a workflow worker thread without debug_mode raises a clear RuntimeError instead of silently hanging.

When debug_mode is not set, the worker's dispatch and sandbox config are unchanged. The defensive hook replaces a silent hang with a clear error — strictly an improvement, not a change to working code.

Why?

breakpoint() and pdb.set_trace() inside workflow code silently hang today. Three overlapping issues:

1. Activations run on a ThreadPoolExecutor thread, so pdb's input() can't read the controlling TTY.
2. The sandbox flags breakpoint as non-deterministic, so the call doesn't reach the debugger.
3. pdb's cmdloop touches more sandbox-restricted internals at runtime (e.g. readline.get_completer) — relaxing the builtin alone isn't enough.

Direct synchronous activation from the dispatch coroutine doesn't work on Python 3.14:

RuntimeError: Cannot enter into task <workflow run task>
  while another task <_handle_activation> is being executed.

The dispatch task is mid-__step() when workflow.activate tries to step the workflow's own task; 3.14 refuses. await future after loop.call_soon suspends the dispatch task first.

Complements #1249 (sandbox passthrough for IDE debuggers). Independent change, different debugger.

Checklist

1. Closes Setting debug_mode in a Worker still doesn't allow the user of breakpoints #1104

2. How was this tested:

• tests/worker/test_breakpoint_hang.py — five tests covering thread placement (both modes), breakpoint in a sandboxed workflow lands at the user's frame with locals visible, q/Ctrl-D continues cleanly, defensive hook raises. 5/5 pass on Python 3.13 and 3.14.
• Manual: drop breakpoint() into any workflow's run() body, run via pytest -s (or a standalone python script), confirm the (Pdb) prompt opens at the user's frame with locals in scope.

3. Any docs updates needed?

• Yes. Adds a "Debugging Workflows with breakpoint() / pdb" subsection to the README under Workflow Sandbox, with a runnable example and the workflow-task-timeout caveat.

[tconley1428]

There's sufficient logic involved here that I think it would be a good idea to move this to a new file. _debugger.py perhaps?

[tconley1428]

Avoid inline imports unless there is a good reason. I think pdb has sufficient justification to do so, but probably not this internal import.