Establish first-class adapter packs for the high-value open tool ecosystem

[szmyty]

Outcome

Turn Renderflow's external-tool support into a deliberate adapter ecosystem rather than a collection of command snippets.

The target is a broad local-first toolbox that can satisfy as much of an artifact forest as possible while keeping every provider replaceable, capability-declared, version-probed, validated, and provenance-aware.

Architecture

Organize adapters by capability/family rather than embedding provider names into core domain logic. A conceptual layout may resemble:

adapters/
  documents/
  pdf/
  images/
  audio_video/
  ebooks/
  office/
  archives/
  data/
  ocr/
  subtitles/

Each provider adapter must declare what it actually does and should use the shared process/tool/artifact contracts from the foundation issues.

Candidate ecosystem to evaluate

Do not adopt every candidate automatically. For each category, perform an adopt/adapt/reject decision based on capability coverage, portability, licensing, maintenance, deterministic behavior, output quality, and validation support.

Candidate classes include:

• document/publishing conversion and typesetting
• PDF inspection/rendering/repair/preflight
• image raster/vector conversion and metadata handling
• audio/video probing and transcoding
• office document conversion/extraction
• e-book conversion/validation
• archive inspection/extraction/creation
• structured-data normalization/querying
• OCR and scanned-document extraction
• subtitle/transcript conversion

Existing Pandoc, Tectonic, FFmpeg, EPUB/KEPUB #344, and HandBrake #345 work should become providers inside this model rather than special cases.

Adapter contract

Every adopted adapter must declare at minimum:

• stable provider ID and version compatibility
• supplied capability/transform IDs
• accepted input and produced output artifact types
• required runtime/tooling
• deterministic status
• loss/fidelity profile
• local/network behavior
• expected side effects
• validation strategy
• config schema/options
• provenance contribution
• representative fixtures

Selection and fallback

Allow multiple providers to satisfy the same capability. Planning should select among them using explicit policy such as availability, quality, cost, determinism, locality, user preference, and platform support.

Do not hide provider substitution after planning.

Acceptance criteria

• A documented adopt/adapt/reject matrix evaluates candidate tool classes and records rationale.
• Adopted adapters use Centralize and harden external tool execution with bounded process policies #356 for external execution and Create a runtime tool capability registry and reproducible toolchain fingerprint #359 for capability/version discovery.
• No provider name becomes a core format/domain concept solely for convenience.
• At least document/PDF, image, audio-video, archive/data, and extraction/OCR adapter families have one verified provider path where practical.
• Existing Pandoc/Tectonic/FFmpeg behavior is represented through the same adapter contracts.
• Evaluate and implement EPUB and KEPUB derivative support #344 and Define the HandBrake transform adapter and Aniflow boundary #345 can integrate as ordinary providers/capabilities.
• Multiple providers for the same transform can be ranked or selected explicitly.
• Every advertised adapter capability has a fixture and validator or is marked experimental.
• Generated capability documentation shows provider requirements and supported platforms.
• The base Renderflow core remains usable without installing the full maximal tool suite.
• Formatting, Clippy, tests, docs, and CI pass.

Dependencies

Depends on #352, #356, #359, and #360. This issue should coordinate with existing #344 and #345 rather than duplicate them.