Identify worker startup timeout before task polling

[rmcdaniel]

Problem

When the workflow wait budget expires during Server discovery or registration, run_until() reports only that the workflow has not reached a terminal state. A published delayed-reply experiment in #123 demonstrates registration can commit while the SDK still waits for its reply and has not begun polling.

Change

Identify startup timeouts with the worker, workflow and existing wait budget. Preserve the generic workflow timeout after startup, the original exception cause, the same deadline and current cleanup authority. Document how startup, drain and replacement work fit together.

Two executing regressions cover held discovery and held registration. The existing post-startup timeout remains a control. The deliberate real Server experiment preserves the original 30-second budget and proves a replacement can finish the same original run once.

Scope and delivery

This improves diagnostics. It does not identify why the original unconstrained registration reply was delayed, and #123 remains open. Main contains an unqualified Nexus producer candidate, so stable delivery must use a narrow backport from the published stable line.

Focused tests and Ruff pass. Normal source checks are next, followed by the stable backport and affected published-package verification. No Server wire or worker-incarnation contract changes.

Related to #123.