Clarify ignore_unhealthy_builders behavior for unhealthy builders

# Finding: Clarify `ignore_unhealthy_builders` semantics

## Affected Path

- `crates/rollup-boost/src/cli.rs`
- `crates/rollup-boost/src/server.rs`
- `crates/rollup-boost/src/tests/unhealthy_builder_traffic.rs`

## Trigger

The `ignore_unhealthy_builders` flag appears to have ambiguous semantics across its CLI help text, implementation, and test comments.

The CLI help says:

```rust
/// Allow all engine API calls to builder even when marked as unhealthy
#[arg(long, env, default_value = "false")]
pub ignore_unhealthy_builders: bool,
```

This reads as: when the flag is true, rollup-boost should ignore the unhealthy health state and continue sending builder Engine API calls.

The current implementation skips builder traffic when the flag is true and the builder is unhealthy:

```rust
fn should_skip_unhealthy_builder(&self) -> bool {
self.ignore_unhealthy_builders && !matches!(self.probes.health(), Health::Healthy)
}
```

The current unhealthy-builder traffic test also configures
`ignore_unhealthy_builders=true`, but later comments/assertions describe the scenario as `flag=false`.

## Impact

The observable behavior may be surprising for operators:

- `ignore_unhealthy_builders=false` currently means unhealthy builders still receive Engine API calls.
- `ignore_unhealthy_builders=true` currently means unhealthy builders areskipped.

That seems opposite to the CLI help text if "ignore" refers to ignoring the unhealthy health state.

## Suggested fix

I think the cleanest fix would be to first clarify whether `ignore_unhealthy_builders` is meant to ignore the unhealthy status and continue sending builder calls, or to ignore/skip unhealthy builders. Once that intended behavior is confirmed, the predicate, CLI help text, and test comments can be aligned in a small follow-up PR.

Start by reading the CLI definition in crates/rollup-boost/src/cli.rs, should_skip_unhealthy_builder in crates/rollup-boost/src/server.rs, and the scenario in crates/rollup-boost/src/tests/unhealthy_builder_traffic.rs. Confirm the intended meaning of the flag with maintainers before changing anything. Done means the predicate, CLI help text, test configuration, comments, and assertions consistently describe the confirmed behavior.

Written by the indexing model from the issue text.