fix: warn when a plugin ships an undiscoverable sensor manifest (2.5.32)

[apackeer]

Problem

Sensor manifest discovery does a FLAT scan of /sensors/ and indexes only basenames matching aidlc-.md (aidlc-graph.ts loadSensors / SENSOR_FILE_REGEX); anything else is silently skipped. Unlike the stages/scopes/agents copy paths, the plugin compose hook's sensor copy shipped no name precheck, so a plugin sensor manifest under any other name - or nested in a subdirectory the flat scan never reads - composed successfully but was never picked up by graph compile or sensor dispatch. The plugin author gets no signal at all: the sensor simply never fires.

What changes

• New sensorManifestNamePrecheck() in the plugin compose hook template, wired into the sensors/ copy: any sensors/*.md that discovery would not index (wrong prefix, or nested in a subdirectory) is skip-and-dropped as a [degraded] drop naming the file and the required aidlc-.md shape - the dead file never lands in the install.
• Already-landed manifests from an older compose hook are audited up front on the next compose (mirrors the existing unsupportedRuntimeModePrecheck posture), so an upgrade cannot leave a dead sensor silently in place.
• Because the drop uses the existing [degraded] channel, /aidlc --doctor surfaces it with zero new plumbing.
• Docs: the plugin authoring guide's Sensors section and the plugin-mechanism reference now state the naming requirement and the guard.
• New unit test t262-plugin-sensor-name-guard: fixture plugin with a mis-named and a nested manifest - warning fires, compose still succeeds, doctor sees the drop.

Never fatal: compose completes; the author gets a precise, actionable message instead of silence.

Version 2.5.32 + CHANGELOG + README badge (re-slotted from 2.5.20 after 2.5.30/2.5.31 landed on v2; the test moved t252 -> t262 because #667 took t252).

Testing

• smoke+unit: 179 files, 4401 assertions, 0 failed (t252 5/5) on the reviewed head; re-run post-rebase on the 2.5.32 head: 183 files, 4468 assertions, 0 failed (t262 5/5)
• integration --filter t188 (plugin-compose pin): 60/0 PASS
• bun scripts/package.ts --check clean across all 5 harnesses (incl. regenerated dist plugin hooks); bun run typecheck clean; coverage registry fresh

[leandrodamascena]

Thanks for tightening this failure mode. I verified that the precheck matches sensor discovery for supported .md names and correctly rejects nested manifests. The focused tests, typecheck, package parity, and doctor drop path are all sound.

A few non-blocking notes:

• The .md check is case-sensitive, so aidlc-foo.MD can still land silently while discovery ignores it.
• A malformed manifest left by an older composer is not audited after the plugin removes or renames its source file.
• t252 is already used by another test; renumbering would avoid bookkeeping ambiguity.
• The branch needs rebasing and re-versioning against the current v2.

None of these should block the core fix.