[FLO-OBS-06] Migrate the suite and enforce observability conformance

[szmyty]

Parent: #14
Depends on: FLO-OBS-04 / #18, and FLO-OBS-05 / #19 only if #18 selects a shared package

Outcome

Apply the accepted observability architecture to flow, aniflow, optiflow, and renderflow through independently reviewable repository changes, then prove that released boundaries behave consistently.

This Flow issue coordinates the rollout and owns the cross-product conformance evidence. Each implementation remains in its owning repository with its own issue, branch, PR, release decision, and rollback path.

Scope

• Create or reconcile one bounded migration issue in each participating repository.
• If a shared package was selected, publish and pin an immutable version before the first consumer migration.
• If repository-local adapters were selected, reuse the normative profile and conformance fixtures without copying policy prose.
• Migrate one product at a time and preserve its native result, diagnostic, progress, evidence, and exit semantics unless a versioned migration explicitly changes them.
• Preserve optiflow's single buffered JSON result and strict machine stdout ownership.
• Preserve aniflow's machine envelopes, provider execution evidence, and Pipeline v2/v3 compatibility boundaries.
• Preserve renderflow's validated pilot behavior and progress integration.
• Make the future flow CLI create the suite root span and propagate context only through reviewed participating adapters.
• Add product/version/command/run/stage/provider/capability/validation/outcome correlation where the field is available and permitted.
• Document unsupported or unavailable signals rather than fabricating them.
• Keep export opt-in, bounded, backend-neutral, and non-authoritative.

Flow-owned conformance kit

Exercise independently built binaries or released libraries through public boundaries. Cover at least:

• human success, warning, partial, failure, cancellation, and interruption;
• JSON/machine success and typed failure;
• stdout/stderr separation under maximum verbosity;
• quiet, level/filter, human/JSON Lines, file, no-color, TTY, and non-TTY modes;
• repeated and embedding-controlled subscriber initialization;
• redaction canaries across console, file, diagnostic bundle, and OpenTelemetry projections;
• default no-network behavior;
• optional local collector export of logs, metrics, and traces;
• cross-process parent/child correlation and non-participating child isolation;
• collector unavailable, slow, rejecting, backpressured, and shutdown-timeout behavior;
• deterministic plan, cache, lock, fingerprint, output, and evidence identity with telemetry varied;
• bounded queue, file rotation/retention if selected, flush, and shutdown;
• stable/MSRV/platform and feature-matrix builds.

The conformance kit must not import sibling source trees or depend on human console prose.

Migration requirements

Each product migration must:

• pin its exact starting revision and existing public behavior;
• use public library and CLI boundaries;
• preserve library subscriber ownership;
• update CLI/configuration documentation and changelog;
• add targeted performance and binary-size evidence;
• include rollback instructions;
• publish or link an immutable compatible release before this coordination issue marks it complete;
• link exact CI runs and contract fixtures here.

Acceptance criteria

• All four products have explicit migration dispositions: delivered, blocked, intentionally deferred, or inapplicable with evidence.
• Every delivered migration has its own owning-repository issue and focused PR.
• Shared dependencies, if selected, use released semver versions rather than paths or mutable Git branches.
• No holon depends directly on a sibling holon or on Flow orchestration.
• Independently built products pass the same applicable conformance corpus.
• A representative flow run correlates participating holon work end to end.
• Non-participating providers receive no trace context.
• Telemetry-disabled execution performs no export or background collector work.
• Varying log level, sink, exporter, sampling, or collector availability does not change authoritative outputs or deterministic identities.
• Product-specific diagnostics, validation, progress, and evidence remain owned by their products.
• Compatibility and deprecation changes are explicit and tested.
• Exact PR, commit, workflow, package/release, and rollback evidence is linked to [EPIC] Establish suite-wide observability and CLI experience #14.

Explicit non-goals

• One cross-repository implementation PR.
• Lockstep releases.
• A unified domain error vocabulary.
• Hosted observability infrastructure.
• Product analytics.
• Treating trace completion as workflow completion.
• CLI ASCII branding.
• Unrelated provider or pipeline refactoring.

Roadmap-Track: FLO-OBS