Extend control-flow termination analysis to loops

## Description

PR #1139 introduced control-flow termination analysis and stops translating a block after a terminating statement. The current implementation covers direct termination (`return`, `exit`, and `fail`) and conditional constructs, but loop-related control flow still needs dedicated handling.

Follow-up to:
- #1139
- https://github.com/amber-lang/amber/pull/1139#discussion_r3590029161
- https://github.com/amber-lang/amber/pull/1139#discussion_r3629492084

## Scope

Extend termination analysis to cover:

- `InfiniteLoop`
- `WhileLoop`
- `IteratorLoop`
- loop bodies and nested blocks
- `break` and `continue`, with behavior evaluated in the context of their enclosing loop
- `CommandModifier` blocks where applicable

The analysis should distinguish between terminating the current block/function and only changing control flow within a loop. In particular, `break` and `continue` must not be treated like unconditional function-level termination outside the correct loop context.

## Acceptance criteria

- Loop syntax modules participate in control-flow analysis.
- Nested loop blocks are analyzed correctly.
- `break` and `continue` are handled according to their enclosing loop.
- Translation does not incorrectly remove reachable statements after a loop.
- Tests cover infinite, while, and iterator loops, including nested conditionals and `break`/`continue` paths.
- Existing control-flow behavior introduced in #1139 remains covered by tests.