DISCLAIMER: at this point, this is just an experiment, so don't rely on
this branch unless you know what you are doing.

The workflow only triggers on master, so nothing on this branch — including
pull requests into it — has ever been exercised by CI. And no job uses a
free-threaded interpreter, so the branch that exists in order to be
free-threaded is not tested as one.

This adds `free-threaded` to the push and pull_request filters, and one job
that runs the test suite on 3.14t.

The job asserts `sys._is_gil_enabled()` is False before it installs anything.
Without that check the job can go green while proving nothing: if the runner
ever resolves 3.14t to a GIL-enabled interpreter, every test below still
passes, and the tick would mean "the default build works", which the existing
job already covers.

Deliberately minimal — build and pytest only. Doctests and stubtest are left
to the existing job rather than duplicated here.

Both skip conditions call sys._is_gil_enabled() at module scope, and that
attribute only exists on 3.13+. On anything older the call raises
AttributeError during collection, so pytest aborts before running a single
test:

    ERROR collecting tests/test_circular.py
        not sys._is_gil_enabled(),
    E   AttributeError: module 'sys' has no attribute '_is_gil_enabled'

That is not hypothetical on this branch. Its CI pins 3.11, and cibuildwheel
runs the suite against every wheel it builds, so the same error takes out the
test job, the debug job and the macOS wheel job — one cause, three red jobs.
It went unseen because the workflow only triggers on master, so CI has never
run on this branch at all; the previous commit fixes that half.

getattr(..., lambda: True) keeps the behaviour identical on 3.13+ and treats
older interpreters as GIL-enabled, which they are.