Plugin refactor + classifier support + idempotency

[joefutrelle]

Plugin refactor + classifier support + idempotency

Refactors the plugin system to use dependency injection so the core never imports plugins at load time. Plugins are now generic and parameterized; instrument-specific presets (IFCB features, IFCB CNN classification) move under improv.plugins.ifcb and pin a kind/index_table onto a generic plugin. Adds machine classification support end-to-end and makes provenance/index writes idempotent.

Highlights

• Plugin DI — plugins register at runtime instead of being imported by the core; store/indexes.py removed, store/dedup.py added.
• Classification — new classification plugin, router, and schema (class-scores schema change); taxonomy registration/lookup plus stateless and decoded read paths; 002_classifier_taxonomy migration.
• Idempotency — append-only writes deduplicated at read time; provenance records keyed by (image_id, kind, source, data_hash) using RFC 8785 (JCS) canonical hashing (new rfc8785 dep). Backend-agnostic (VAST DB / DuckDB+Parquet).
• Small-batch POST — POST /images/provenance/batch lets low-volume producers write provenance over REST without depending on the columnar store (one instrument per batch).
• Client — ImprovClient gains taxonomy registration.
• Tests — added coverage for classification, provenance, client, plugins, store dedup (~590 net test lines).
• Docs — README updated (plugin model, classifier API, idempotency, client contract on event-time timestamp).

Review note: client contract — timestamp must be event time, not wall-clock-at-send, or retries won't dedup.

[johnwaalsh]

I wonder if there's a way we could further describe the difference between low-volume and high-volume producers. Perhaps some examples of what kind of data would be best for the REST API, and what kind of data would be best for the columnar store?

[joefutrelle]

Yes, this could be elucidated further. The primary use case would be for data coming in small batches in near-real time.