fix(ai): a GPU-holding Python process was reported as PyTorch

`detect_workloads` promoted an unidentified framework to `PyTorch` whenever the
process held a GPU. That guess reached users: it flows into
`signals.ai_frameworks`, which `tuning::classify` publishes beside the evidence
string "an AI framework was identified in a running process" at 0.8-0.9
confidence, outranking every utilisation heuristic below it.

A Python process on a GPU is as likely to be JAX, TensorFlow, ONNX Runtime or
vLLM -- or a CUDA program that is not machine learning at all. Identified is
precisely what it was not.

This is a different failure mode from the rest of today's sweep. Every other
defect invented a *number*; this invented an *identity*, and a second module then
attested to it. A wrong number invites a sanity check. A plausible framework name
does not, and `simon tune` is where acting on it has consequences.

`ai_present` is unaffected -- holding a GPU is still evidence of an AI workload.
Only the claim about which framework is withdrawn.

Dropping it exposed a second-order defect: `format!("{:?}")` over `Unknown` would
have put the literal "unknown" into the framework list, which is the absence-word
defect `push_str_as` guards against in the ontology arriving through a different
door. `serve.rs` now filters it.

Also removes an assumption in `dma_engine`, which claimed memcpy support whenever
the `cap` sysfs file was unreadable. An unreadable file is not evidence of a
capability. Latent -- nothing calls it -- but safe to correct, since it only ever
removes a claim.

Verified: both cross-target checks with `--all-targets`, fmt, clippy
`-D warnings`, 826 lib tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>