Fix synchronous batch timeout tracking

[bretep]

What does this PR do?

Restricts the shared batch state machine's internal wall-clock timeout sweep to
master-driven asynchronous batches.

The synchronous CLI driver already has an authoritative LocalClient return
iterator. That iterator probes saltutil.find_job and stays alive while a job
is running, then reports a timeout through the existing timed_out input when
tracking ends without a return. Applying a second wall-clock sweep to the CLI
driver releases its slot prematurely and allows the next sub-batch to start
while the original job is still running.

What issues does this PR fix or reference?

Fixes #70018

Previous Behavior

After timeout + gather_job_timeout, a synchronous batch moved an active
minion to failed and dispatched another minion even if the return iterator
was still tracking the running job.

New Behavior

Synchronous batches keep a slot occupied until the return iterator yields the
minion result or exhausts and reports a timeout. Master-driven asynchronous
batches retain their existing internal wall-clock timeout.

Regression tests

• A state-machine test verifies that elapsed wall-clock time alone cannot free
  a CLI batch slot and that an explicit iterator timeout still can.
• A Batch.run() test keeps a synthetic return iterator alive beyond the
  timeout window and verifies that the next sub-batch is dispatched only after
  the first result arrives.
• Both tests fail against the previous logic and pass with this change.
• All 43 tests in the affected unit-test files pass.

Merge requirements satisfied?

• Docs (state-machine documentation updated)
• Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• Tests written/updated

Commits signed with GPG?

No