Honor configured session timeout for Copilot dialog turns

[PolyphonyRequiem]

Summary

• replace the hard-coded 120-second Copilot dialog wait with the provider's configured max_session_seconds
• classify dialog timeout as retryable so callers can continue the existing dialog
• add regression coverage and an Unreleased changelog entry

Problem

CopilotProvider.execute_dialog_turn() ignored runtime.max_session_seconds and always timed out after 120 seconds. Long reasoning responses could therefore fail even when the workflow explicitly allowed a longer session.

Validation

• PYTHONPATH= ./.venv/Scripts/pytest.exe tests/test_providers/test_copilot.py — 128 passed
• Ruff check and format check passed for changed files
• ty check src/conductor/providers/copilot.py passed

[jrob5756]

Nice to see your name again 😄. I like the change. Just two minor inline notes worth a look before merging: the is_retryable flip doesn't seem to reach any code that checks it, and reusing max_session_seconds for a single flat wait removes the fast-failure behavior without putting anything back in its place. Lint, types, and the full suite all pass, and the new regression test is solid (I reverted the fix locally and confirmed it fails).

[jrob5756]

This bumps the default dialog-turn timeout from 120s to 1800s for anyone who hasn't set runtime.max_session_seconds, and it's a single flat wait_for with none of the periodic idle-check/recovery logic the main agent loop has around this same config value. If a dialog session genuinely hangs, a console or web user could be staring at nothing for 30 minutes before seeing an error.

Would a shorter, dialog-specific default (or at least a log line once idle_timeout_seconds has elapsed) be worth adding here, so a stall isn't completely silent until the full deadline hits?

[jrob5756]

Neither gates/dialog.py nor dialog_evaluator.py look at .is_retryable on this error — both just catch a bare Exception and move on. So this flip doesn't change any observable behavior today, and it puts this raise at odds with the main execution loop, which treats the identical max_session_seconds timeout as non-retryable on purpose (see the # Don't retry — same root cause will recur comment a bit further up in this file).

If there's a future retry path planned for dialog turns, a short comment here explaining the divergence would help the next person who reads this. Otherwise I'd lean toward keeping this False to match the main loop.

Suggested change

	is_retryable=True,
	is_retryable=False,

[jrob5756]

Minor: the "so console and web dialogs can continue without losing history" part already happens today regardless of is_retryable — both dialog call sites roll back the user turn and continue on any exception, not just retryable ones. Might be worth tightening this to just describe the timeout fix itself.