fix(a11y): a disabled control answers the pointer with not-allowed (#5323)

The cursor is the only affordance a pointer user gets before they commit
to a click. A disabled control answering with `pointer` promises a click
it will not honour; one answering with `default` says nothing at all.

Every `cursor` in core and lab now carries
`':is(:disabled,[aria-disabled="true"])': 'not-allowed'`, the reset gives
the same cursor to any disabled element that declares none, and a lint
rule plus a Chromium sweep keep it that way.

Author: cixzhang

.changeset/disabled-cursor-guarantee.md

@@ -0,0 +1,7 @@
+---
+'@astryxdesign/core': patch
+---
+
+[fix] A disabled control now answers the pointer with `not-allowed` wherever it can be pointed at: every `cursor` in core and lab carries `':is(:disabled,[aria-disabled="true"])': 'not-allowed'`, and the reset gives the same cursor to any disabled element that declares none — `[aria-disabled]` included, where it previously said `default` and only for native `:disabled`. A lint rule and a Chromium sweep over every story keep it that way. Disabled elements sealed behind `pointer-events: none` are unchanged: the pointer never reaches them, so their cursor comes from an ancestor.
+
+@cixzhang