[!abc] matches a, b and c: POSIX-style bracket negation is inverted unless options.posix is set

[!abc] matches a, b and c: POSIX-style bracket negation is inverted unless options.posix is set

### Summary

`[!abc]` is treated as a character class **containing** `!`, so it matches exactly the characters it is supposed to exclude. It is inverted, not merely unsupported.

```js
const pm = require('picomatch')

pm.isMatch('a', '[!abc]')  // true   <- should be false
pm.isMatch('d', '[!abc]')  // false  <- should be true
```

bash, for reference:

```
$ case a in [!abc]) echo match;; *) echo "no match";; esac
no match
$ case d in [!abc]) echo match;; *) echo "no match";; esac
match
```

`minimatch` agrees with bash on every case I tried. `micromatch`, `fast-glob` and anything else built on picomatch inherit the inversion.

### The generated regex shows what is happening

```js
pm.makeRe('[!abc]').source
// ^(?:(?:\[!abc\]|[!abc])\/?)$

pm.makeRe('[^abc]').source
// ^(?:[^abc/]\/?)$
```

For `[^abc]` the `^` is read as negation and the result is correct. For `[!abc]` the `!` is emitted as an ordinary class member, so the class is "one of `!`, `a`, `b`, `c`".

### `options.posix` fixes it, but that is not what the option is documented to do

| | `posix: false` (default) | `posix: true` | bash |
|---|---|---|---|
| `[!abc]` vs `a` | **true** | false | no match |
| `[!abc]` vs `d` | **false** | true | match |
| `[[:alpha:]]` vs `a` | true | true | match |
| `[^abc]` vs `a` | false | false | no match |

Two things stand out in that table.

`[[:alpha:]]` matches with the option **off**. So the flag documented as

> `posix` — Support POSIX character classes ("posix brackets").

is not in fact gating POSIX character classes; those already work. What it actually gates is `[!...]` negation, which is a different feature. `[!...]` is ordinary Bash pattern negation, not a POSIX bracket expression like `[[:alpha:]]`.

And `[^...]` negation works with the option off, so the two negation forms disagree with each other by default.

The README states:

> full support for standard and extended Bash glob features

which `[!...]` squarely is.

### Not a regression

picomatch 2.3.1 produces `^(?:(?:\[!abc\]|[!abc])[\/]?)$` for the same pattern, so this has been the behaviour for a long time. I could not find an existing issue for it; #148 and #154 are about extglob `!(...)`, which is a separate mechanism.

### Why it matters

`[!...]` is the form people copy out of shell scripts, `.gitignore` documentation and POSIX references, and it fails silently. Nothing throws and nothing warns; the matcher just returns the complement of what was asked for. With picomatch at roughly 440M downloads a week, and micromatch, fast-glob and chokidar on top of it, a quietly inverted result seems worth a look even if the eventual answer is a documentation change.

### Possible directions

1. Treat a leading `!` immediately after `[` as negation regardless of `options.posix`, matching `[^...]` and bash. Most correct, but it changes default matching behaviour, so it is your call whether that needs a major.
2. Leave the behaviour and fix the documentation, saying plainly that `[!...]` needs `posix: true` while `[^...]` does not, and correcting the `posix` description since POSIX classes work without it.
3. Warn on a bracket expression starting with `!` when `posix` is false.

Happy to open a PR for whichever you prefer, with tests.

Checked against picomatch 4.0.5 and 2.3.1 on Node 24.