A `BigInt` division panics, and two neighbouring operations answer wrongly in silence

Summary

`viperjs` is a JavaScript engine intended to run untrusted script inside a host application, so script text is data rather than a trusted caller and a panic reachable from script is a denial of service in the embedder's process.

A divisor whose magnitude lands exactly on the engine's internal limb ceiling reaches an out-of-bounds index. On every released version up to and including 0.2.1:

```js const d = (1n << 33554399n) * 2n; 1n / d; // panic: index out of bounds ```

Two further operations on the same value returned wrong results without raising anything, which is the more dangerous half for an embedder that acts on the answer:

```js d % 7n; // 0n — the true remainder is 1n String(d); // "0" ```

## Cause

The left-shift helper reserved one limb for the bits a shift may push past the top of the magnitude, measured *that* width against the size ceiling, and then trimmed the reserved limb away again — so a magnitude landing exactly on the ceiling was refused on account of room it does not keep. The division treated that refusal as unreachable and discarded it with `unwrap_or_default`, leaving an empty divisor magnitude; the subsequent `divisor[n - 1]` is then an index of `usize::MAX`.

The crate is `#![forbid(unsafe_code)]`, so this is a panic and not memory unsafety.

## Remediation

Upgrade to 0.2.2, in which all three behaviours are fixed: both divisions now produce correct results, and `String()` of a magnitude beyond what the engine can divide raises a `RangeError` rather than producing `"0"` — ECMA-262 §6.1.4 requires an implementation that imposes a limit to throw rather than answer something else.

There is no workaround short of upgrading; the values are reachable from any script the embedder evaluates.

Reported by [@Zniece](https://github.com/Zniece).