Read every history page when resolving workflow results

[rmcdaniel]

Summary

• Follow Server history page tokens when resolving a terminal workflow result, using pages of at most 1,000 events.
• Let callers request a specific history page through Client.get_history() and WorkflowHandle.get_history().
• Detect a repeated page token instead of looping indefinitely.

Evidence so far

• Published Server 2.4.19 (sha256:77a61a9f46ca9765ee86174b9a50dab1b9e810250caa9e3551b800457a81862a) completed a 100-side-effect workflow and reported output 4950. Published Python SDK 2.3.4 returned None because its default 100-event history page omitted the terminal event.
• The candidate source mounted over the published SDK dependencies returned 4950 for a fresh 103-event run against that Server digest.
• tests/test_client.py and tests/test_workflow_result_timeout.py: 202 passed in an isolated Python 3.12 container.
• The candidate source also completed a fresh 1,050-side-effect and 13-activity run with 1,092 ordered events in two history pages. It returned 550725, the expected result, against the same published Server digest. Raw evidence is in Qualify long-lived workflow histories on published Server artifacts server#245.
• All PR checks passed, including Python 3.10/3.11/3.12, lint, package, docs, and integration. Local focused tests passed 202/202. A broader local run passed 1,470 tests but two scanner fixtures could not start because the slim disposable Python container lacked git; CI's complete unit matrices passed.

Related: #81 and durable-workflow/server#237.