fix(extras): stop following redirects in the MicroVM request step - #1036

The send_job docstring said that the JavaScript operation follows
redirects. aws/aws-durable-execution-sdk-js#1036 changed that. The
JavaScript request step now fails every 3xx at once. So the docstring
contradicted the corrected README sentence.

The docstring now states that neither operation follows a redirect.
It then states why: a followed 301, 302, or 303 would send a GET
without the job, and a followed 307 or 308 to another host would
receive the auth token.

* test(extras): end the invocation between two jobs

Two session tests of #811 check the resume mode across a deploy. The
handler counts its invocations. The first invocation uses the launch's
config. Every later invocation uses the deployed config. Each test runs
two jobs and asserts len(invocations) > 1.

1. The run fixture completes each callback as soon as the job creates
   it.
2. A checkpoint response carries every operation that changed since
   the last response.
3. So the first callback's result can reach the first invocation.
4. So both jobs can be delivered in the first invocation, with the
   launch's config.
5. A suspension while the second job waits then satisfies
   len(invocations) > 1. No job is delivered after the deploy.
6. If both callbacks complete early, the execution ends in one
   invocation. The assertion then fails.

The Codex review of #811 reported this race. In 65 local runs of the
old test body, the second job was delivered in invocation 2. The test
body did not ensure that order.

The two tests now run a durable wait between the jobs. A durable wait
always ends the invocation. The local runner skips the wait's time. So
the second job is delivered in a later invocation, after the deploy,
in every run.

Each test also records the invocation that sent each request. It
asserts that the first request was sent in invocation 1, and the
second request in a later invocation.

The tests fail against the session code before #811. The failures are
at the GetMicrovm count: 1 instead of 3, and 1 instead of 0.

* docs(extras): state the JS redirect behavior

The README said that the JavaScript operation follows redirects.
aws/aws-durable-execution-sdk-js#1036 changed that. The JavaScript
request step now passes redirect: "manual". It fails every 3xx at
once. The operation then raises MicrovmDeliveryError. So the README
now states that the JavaScript operation also fails every 3xx at once,
with MicrovmDeliveryError.

* docs(extras): fix the send_job redirect docstring

The send_job docstring said that the JavaScript operation follows
redirects. aws/aws-durable-execution-sdk-js#1036 changed that. The
JavaScript request step now fails every 3xx at once. So the docstring
contradicted the corrected README sentence.

The docstring now states that neither operation follows a redirect.
It then states why: a followed 301, 302, or 303 would send a GET
without the job, and a followed 307 or 308 to another host would
receive the auth token.

* test(extras): name the wait between the two jobs

The handler two_jobs_in_two_invocations runs two jobs with a durable
wait between them. The execution runs 4 invocations, not 2. So the
name is now two_jobs_with_a_wait_between.

The SDK's wait returns without a suspension if the START checkpoint
response marks the wait SUCCEEDED. The local runner always answers a
START with STARTED. So the docstring now states that a durable wait
ends the invocation in the local runner.

A request can also time out without an answer. So the comment in
_InvocationLog.append now says that the POST gets an answer or times
out, and that the fake endpoint answers at once.

The sent_in assertions require at least 2 invocations. So the two
deploy tests no longer assert len(invocations) > 1.

* test(extras): end the invocation between two jobs

Two session tests of #811 check the resume mode across a deploy. The
handler counts its invocations. The first invocation uses the launch's
config. Every later invocation uses the deployed config. Each test runs
two jobs and asserts len(invocations) > 1.

1. The run fixture completes each callback as soon as the job creates
   it.
2. A checkpoint response carries every operation that changed since
   the last response.
3. So the first callback's result can reach the first invocation.
4. So both jobs can be delivered in the first invocation, with the
   launch's config.
5. A suspension while the second job waits then satisfies
   len(invocations) > 1. No job is delivered after the deploy.
6. If both callbacks complete early, the execution ends in one
   invocation. The assertion then fails.

The Codex review of #811 reported this race. In 65 local runs of the
old test body, the second job was delivered in invocation 2. The test
body did not ensure that order.

The two tests now run a durable wait between the jobs. A durable wait
always ends the invocation. The local runner skips the wait's time. So
the second job is delivered in a later invocation, after the deploy,
in every run.

Each test also records the invocation that sent each request. It
asserts that the first request was sent in invocation 1, and the
second request in a later invocation.

The tests fail against the session code before #811. The failures are
at the GetMicrovm count: 1 instead of 3, and 1 instead of 0.

* docs(extras): state the JS redirect behavior

The README said that the JavaScript operation follows redirects.
aws/aws-durable-execution-sdk-js#1036 changed that. The JavaScript
request step now passes redirect: "manual". It fails every 3xx at
once. The operation then raises MicrovmDeliveryError. So the README
now states that the JavaScript operation also fails every 3xx at once,
with MicrovmDeliveryError.

* docs(extras): fix the send_job redirect docstring

The send_job docstring said that the JavaScript operation follows
redirects. aws/aws-durable-execution-sdk-js#1036 changed that. The
JavaScript request step now fails every 3xx at once. So the docstring
contradicted the corrected README sentence.

The docstring now states that neither operation follows a redirect.
It then states why: a followed 301, 302, or 303 would send a GET
without the job, and a followed 307 or 308 to another host would
receive the auth token.

* test(extras): name the wait between the two jobs

The handler two_jobs_in_two_invocations runs two jobs with a durable
wait between them. The execution runs 4 invocations, not 2. So the
name is now two_jobs_with_a_wait_between.

The SDK's wait returns without a suspension if the START checkpoint
response marks the wait SUCCEEDED. The local runner always answers a
START with STARTED. So the docstring now states that a durable wait
ends the invocation in the local runner.

A request can also time out without an answer. So the comment in
_InvocationLog.append now says that the POST gets an answer or times
out, and that the fake endpoint answers at once.

The sent_in assertions require at least 2 invocations. So the two
deploy tests no longer assert len(invocations) > 1.