astype resolves longdouble differently from pandas on x86

`test_astype.py::test_every_spelling_means_what_pandas_says_it_means` fails on x86 Linux. It passes on arm macOS, which is why it got through.

```
AssertionError: longdouble: firepanda gave float64 and pandas gave float128
g: firepanda gave float64 and pandas gave float128
```

The cause is not flakiness. numpy's `longdouble` is the platform's extended precision type, so it is `float128` on x86 Linux and an alias for `float64` on arm macOS. The test compares what firepanda resolves a spelling to against what pandas resolves it to, and on a platform where those differ they differ.

There is a decision behind this rather than a one line fix. firepanda has no extended precision float, so `longdouble` and `g` name a precision we cannot represent. Two ways out:

- refuse the spelling, so asking for a type we do not have is an error rather than a silent narrowing to float64
- keep mapping it to float64 and excuse it in the comparison, the way `str` and `string` are already excused

Refusing is the more honest of the two, since quietly handing back half the precision someone asked for is the kind of thing that is found much later. But it makes a spelling pandas accepts an error in firepanda, which is a parity decision, not a test fix.

Found while reproducing #400 on the 13900K. It is separate from that one and will keep the two Linux builds red after #401 pins the interpreter. From #398.

Start by running test_astype.py::test_every_spelling_means_what_pandas_says_it_means on x86 Linux and inspect how astype resolves longdouble and g, including the existing str and string exceptions. Decide which unsupported-precision policy the project should use, then make the test pass on affected platforms while preserving the documented behavior across platforms.

Written by the indexing model from the issue text.