`DecimalNode` to `BigInteger` conversion no longer guarded by `StreamReadConstraints.validateBigIntegerScale()`

In 2.x, every `DecimalNode` → `BigInteger` conversion went through `BaseJsonNode._bigIntFromBigDec()`, which calls `StreamReadConstraints.defaults().validateBigIntegerScale(value.scale())` before `BigDecimal.toBigInteger()` (added for #3864). That guard exists because `toBigInteger()` on a `BigDecimal` with huge scale magnitude is extremely expensive (computes 10^|scale|), while the textual form is tiny — `1e2000000000` is 12 characters, so `maxNumberLength` doesn't help.

In 3.x the guard is gone: `DecimalNode._asBigIntegerValueUnchecked()` is a bare `_value.toBigInteger()` (dropped in the #4970 number-accessor rework). Streaming parsers are still guarded (`ParserBase.convertNumberToBigInteger()`), and `BigIntegerDeserializer` / `TokenBuffer` still validate, but the `JsonNode` accessors are not:

```java
ObjectMapper mapper = JsonMapper.builder().enable(DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS).build();
JsonNode n = mapper.readTree("1e2000000000");
n.bigIntegerValue(); // CPU/memory DoS, no StreamConstraintsException
```

Same via `TreeTraversingParser.getBigIntegerValue()` (which is also how tree-backed format parsers such as TOML expose numbers), and via `asBigInteger()` / `bigIntegerValueOpt()` etc. — all six accessors funnel through `_asBigIntegerValueUnchecked()`.

Fix: restore the check in `DecimalNode._asBigIntegerValueUnchecked()` (using `StreamReadConstraints.defaults()`, as 2.x did, since nodes don't carry the configured constraints). PR to follow.

Start at DecimalNode._asBigIntegerValueUnchecked() and compare its conversion with the existing StreamReadConstraints validation described for 2.x and streaming parsers. Restore validation using StreamReadConstraints.defaults(); done means values with huge BigDecimal scales raise StreamConstraintsException instead of performing an expensive conversion.

Written by the indexing model from the issue text.