significant_terms on a floating-point field returns 500 (UnsupportedOperationException) instead of 400

## Summary

A `_search` with a `significant_terms` aggregation on a floating-point field returns HTTP **500** (`search_phase_execution_exception`) instead of a client error.

Seen on serverless 9.6.0, `POST /logs-*/_search`, Kibana log-rate analysis (`sig_term_p_value_*` agg name, nested under `random_sampler`). Two shards failed during query; the coordinating node then failed fetch/reduce.

## Stack trace (redacted)

```
SearchPhaseExecutionException: Failed to execute phase [fetch]
shardFailures:
QueryPhaseExecutionException: Query Failed [Failed to execute main query]
Caused by: UnsupportedOperationException: No support for examining floating point numerics

Caused by: IllegalArgumentException: Merging/Reducing the aggregations failed when computing the aggregation [sig_term_p_value_11] because the field you gave in the aggregation query existed as two different types in two different indices
at AggregationErrors.reduceTypeMismatch
at InternalSignificantTerms
at InternalRandomSampler
at QueryPhaseResultConsumer.aggregate → FetchSearchPhase
```

## Root cause

`SignificantTermsAggregatorFactory.numericSupplier()` throws a raw `UnsupportedOperationException` when the values source is floating-point:

https://github.com/elastic/elasticsearch/blob/main/server/src/main/java/org/elasticsearch/search/aggregations/bucket/terms/SignificantTermsAggregatorFactory.java#L178-L181

```java
if (numericValuesSource.isFloatingPoint()) {
throw new UnsupportedOperationException("No support for examining floating point numerics");
}
```

The same factory already uses `ElasticsearchStatusException(..., RestStatus.BAD_REQUEST)` for an analogous validation (sampling + `min_doc_count`). The float check should do the same (or `IllegalArgumentException`, matching the regex include/exclude check a few lines above).

The `reduceTypeMismatch` `IllegalArgumentException` is a second, related failure: `logs-*` spans backing indices where the aggregated field is not the same type. That path also surfaces as 500 because it happens during fetch/reduce after the shard-level UOE.

## Expected

- **400** with a clear message that `significant_terms` does not support floating-point fields.
- Mixed field types across indices in the same agg should also be a **400**, not a 500.

## Related

- Same `reduceTypeMismatch` / `sig_term_p_value_11` stack was reported on a suppressed-rest-errors alert on 2026-02-12; no GitHub issue was filed then.
- Pattern match: #154354 (`UnsupportedOperationException` → 500 instead of 400).