two more fleet-noise sources: socket's int-as-fd family and logging's level constant

[devdanzin]

Both found while re-triaging the completed fusil-pypy311_fleet_08 (--concurrency-stress,
158 827 sessions, 548 crashes, 229 kept dirs). Together they account for 177 of those 229
dirs — 77% of everything the fleet kept was fusil hurting itself or scoring an echo.

1. socket.close / dup / fromfd / send_fds take a raw integer fd — 163 dirs

The int-as-FD analogue of the int-as-pointer family already excluded in CTYPES. Handing any
of them a fuzz integer closes or reinterprets a descriptor the interpreter is still using. Not
a target defect — the contract is the argument: close(integer) does exactly what it is told,
on any interpreter.

The bucket looked like two problems and is one. It splits exactly on the value passed:

face	dirs	what happened
socket-fatal_python_error	120	closed some other descriptor; glibc's own Unexpected error 9 on netlink descriptor 11 survived to stdout — 11 being socket.AF_ROSE, which the stress region had picked as a shared object
socket-sigabrt	43	SIGABRT with an empty stdout — and all 43 shared a constant worth 0, 1 or 2. They closed the child's own stdout or stderr, so the diagnostic had nowhere to go

43/43 is the whole reason to believe the account rather than extrapolate from the noisy face.

One correction to the evidence, made before shipping. My first draft of this said "CPython
aborts on it too", carried over from the snapshot triage, which had measured PyPy 6/6 against
CPython 1/6. Re-checking it: a standalone harness closing fd 11 while sibling threads call
getaddrinfo is 0/6 on both interpreters, across two fd ranges and two rates — the window
needs the full stress region. I am not carrying that differential forward. Nothing above
depends on it: the message is glibc's __libc_fatal reporting EBADF on a descriptor it owns,
the manifests name the constant whose value is that descriptor, the function is documented as
taking an integer, and 43/43 of the silent aborts carry a 0/1/2 constant.

The entry is module-keyed (BLACKLIST["socket"]), not name-based, and there is a test
pinning that: close and dup are also methods on sockets, files and much else, where they
take no descriptor and are fine to fuzz. A METHOD_BLACKLIST entry would stop fusil ever
closing anything.

This one changes the default fuzzing surface, which is why I have raised it twice without
applying it. Four module-level functions, all documented as taking an integer.

2. warnings echoing logging's source — 14 dirs, and #265 does not cover it

A third face of the self-echo disease. The default warning formatter prints the source line of
whatever frame it fired in:

/.../logging/__init__.py:1536: RuntimeWarning: coroutine '...' was never awaited
  self._log(CRITICAL, msg, args, **kwargs)

So any un-awaited coroutine collected while logging is on the stack echoes logging's own
source, and the CRITICAL in it is the level constant being passed as an argument. It is
neither a File "...", line N, in ... frame nor a .critical( call, so neither #265 rule
reaches it — I checked the two observed lines against the live core_ignore_regexes rather
than assuming, and both still score 1.0 today. 14 dirs across asyncio.base_events,
asyncio.streams and asyncio.selector_events.

The new rule matches the constant only in an argument position and is case-sensitive, so a
real formatted record (CRITICAL:root:...) and English prose ("a critical error") both still
score. Tests cover both directions.

The structural question, still open

This is the fourth echo-noise face patched one at a time, and I do not think the series
converges — warnings, tracebacks and bdb will keep echoing arbitrary source past any
literal list. The alternative I raised after fleet_07 stands: score only diagnostic-shaped
lines, or drop the sub-1.0 words. Not attempted here; this PR is the measured fix for what
fleet_08 actually produced.

Checks

1281 tests OK (~/venvs/fusil_np_verify), ruff check and ruff format --check both clean.