[FLO-OBS-08] Add accessible branded root-help presentation

[szmyty]

Parent: #14
Depends on: FLO-OBS-01 / #15
Recommended sequencing: after FLO-OBS-06 / #20 stabilizes CLI presentation behavior

Outcome

Give flow, aniflow, optiflow, and renderflow a memorable, coherent terminal identity through compact static wordmarks on interactive root help, without changing automation, errors, diagnostics, logs, or machine contracts.

This is a presentation-only checkpoint and remains independent from the observability package.

Scope

• Design a compact repository-owned ASCII wordmark for each lowercase product name.
• Preserve a recognizable family relationship while allowing each holon a distinct identity.
• Show decorative branding only for interactive root help.
• Keep the product name, purpose, usage, commands, and options available as ordinary semantic text.
• Use checked-in static text/assets rather than a runtime FIGlet generator, network lookup, or font dependency.
• Provide a plain/narrow fallback based on available terminal width.
• Make optional color follow terminal capability and NO_COLOR; meaning cannot depend on color.
• Keep root help readable with screen readers and copy/paste workflows.
• Avoid decorative output during normal commands.

Suppress the wordmark for:

• JSON or other machine-result modes;
• redirected or piped help;
• subcommand help unless explicitly justified later;
• parse and usage errors;
• --version;
• shell-completion generation;
• man-page/reference generation;
• TERM=dumb;
• narrow terminals where the compact form would wrap;
• any path where terminal capability cannot be established safely.

Architecture boundary

• Branding belongs to each CLI delivery adapter or a narrowly scoped presentation helper.
• The logging/OpenTelemetry layer must not emit, own, or depend on banners.
• Domain libraries expose no terminal art and remain silent.
• Machine results, typed diagnostics, structured logs, trace events, metric labels, diagnostic bundles, plans, manifests, and artifacts never contain the wordmark.
• User-controlled values cannot be interpolated into static terminal escape sequences.
• Help generation remains deterministic and snapshot-testable.

Accessibility and UX requirements

• The ordinary lowercase product name and purpose precede or follow the art in readable text.
• No state, warning, option, or semantic information exists only inside the wordmark.
• Color contrast follows the eventual terminal design guidance and is never required.
• A plain-text fallback works with screen readers, high-contrast/no-color terminals, and narrow widths.
• Avoid animation, cursor control, sound, blinking, or repeated splash screens.
• Keep the root help concise enough that branding does not bury common commands.

Acceptance criteria

• Every participating CLI has an approved compact static root-help wordmark or an explicit documented deferral.
• Interactive root --help shows the correct product identity without changing exit behavior.
• The lowercase product name and purpose remain available as normal text.
• Machine output, logs, diagnostics, errors, version output, completions, man pages, and ordinary commands contain no banner.
• Redirected/non-TTY, TERM=dumb, narrow, and NO_COLOR output use a clean undecorated fallback.
• No ANSI sequences appear when color is disabled or unsupported.
• Help snapshots cover interactive, non-interactive, narrow, no-color, error, version, completion, and reference-generation paths.
• Existing command parsing and help semantics remain intact.
• Static assets are reviewed for accessibility, width, licensing/provenance, and product-name policy.
• Implementation occurs through separate owning-repository PRs.
• No logging, exporter, planning, execution, validation, or evidence behavior changes.

Explicit non-goals

• Splash screens during normal operation.
• Animated terminal output.
• Runtime font generation.
• Branding inside structured output or diagnostic archives.
• A shared dependency between sibling holons.
• Replacing visual identity systems for websites, icons, or social media.
• Mixing this work into Pipeline v3 or another functional checkpoint.

Roadmap-Track: FLO-OBS