Fix out-of-bounds crash in Stream affinity analysis for scf.while (#24723)

See issue https://github.com/iree-org/iree/issues/24722

The issue contains a deeper explanation of the issue and a repro case
(which is the same as the lit test here).

When an `scf.while` carries more values through its "before" region than
the op has results (i.e. some loop-carried values are not forwarded to a
result via `scf.condition`), the affinity analysis mapped an `scf.yield`
operand number directly onto `whileOp->getResult(operandNumber)`. Since
the "after" region yield has one operand per init operand (`N`) while
the op may have fewer results (`M`), this lead to `getResult()` being
out of bounds.

Two independent sites made this naive mapping:

- **`Affinity.cpp`**: in the `scf.yield` → `scf.while` branch of
`ValueConsumerAffinityPVS::updateFromUse`, drop the
`whileOp->getResult(operandNumber)` propagation and keep only the
before-region-argument propagation. (Results are already handled by the
`scf.condition` case.)

- **`Explorer.cpp`**: guard the `ReturnLike` result-mapping fallback in
`walkTransitiveUses` with
`!isa<RegionBranchTerminatorOpInterface>(ownerOp)` (region-branch
terminators like `scf.yield` are already handled correctly above) plus a
`use.getOperandNumber() < parent->getNumResults()` bounds check.

Added regression test `@scf_while_extra_loop_carried`, which exercises
the `N > M` shape (two loop-carried values, one result) that previously
asserted.

Note that Claude made the fix suggestions and, while they look okay to
me, I'm not at all familiar with this code.

---------

Signed-off-by: Paul Stark <paul.stark@cdprojektred.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Artem Gindinson <gindinson@roofline.ai>