Add a TTY-mode compile_stats integration test (capturing stderr via an os.Pipe) that asserts the large-workflow row contains the styled ✗ workflow string. Compare against styles.Error.Render("✗ " + stats.Workflow) to confirm the single-render path produces the expected ANSI sequence.

If style definitions never include padding/truncation this is a no-op, but an explicit test locks in that invariant.

Follow the existing pattern:

// Consistent with FormatSuccessMessage / FormatSuccessMessageStderr
func FormatTableHeaderStderr(text string) string // keep name, but also add stdout variant if needed
func FormatErrorStderr(text string) string       // instead of FormatErrorTextStderr

At minimum, align the ...Text... vs. ...Message... naming: either rename FormatErrorTextStderr → FormatErrorMessageStderr, or document why this helper intentionally omits the prefix icon that FormatErrorMessage adds.

Make the semantic difference explicit in the name or doc comment. Options:

1. Rename to FormatErrorRawStderr to signal no prefix is added.
2. Add a doc comment that explicitly calls out: // Unlike FormatErrorMessage, this function does not prepend a "✗ " prefix.
3. If the only call site already prepends the prefix manually ("✗ " + stats.Workflow), consider whether a prefixed variant (FormatErrorMessageStderr) would be cleaner and remove the manual concatenation at the call site.

Add smoke tests for the exported functions to lock in the wiring between public function → private helper → TTY check. They do not need to simulate a real TTY; even a non-TTY assertion is enough:

func TestFormatTableHeaderStderr_NonTTY(t *testing.T) {
    // Stdout/stderr are not terminals in test, so plain text is expected
    got := FormatTableHeaderStderr("Mon")
    if got != "Mon" {
        t.Errorf("FormatTableHeaderStderr() = %q, want %q", got, "Mon")
    }
}

This protects the public API contract separately from the internal implementation.

Group the two stderr-specific stubs together or keep them adjacent to their non-stderr counterparts. If the block is intended to be alphabetical, place them in alpha order; otherwise add a short comment separating stderr-specific stubs from the prefix-bearing ones.

The established pattern throughout console.go is a matched pair:

Func FormatXxx(...)         // stdout (calls isTTY)
Func FormatXxxStderr(...)   // stderr (calls isStderrTTY)

This holds for FormatSuccessMessage/FormatSuccessMessageStderr, FormatInfoMessage/FormatInfoMessageStderr, FormatListItem/FormatListItemStderr, and FormatSectionHeader/FormatSectionHeaderStderr.

FormatErrorTextStderr breaks that contract — there is no FormatErrorText. Callers that need to style error text for stdout have no symmetric helper and must reach into styles directly, defeating the purpose of the abstraction.

FormatTableHeaderStderr in the same commit has the same gap.

Suggested fix — add the missing stdout counterparts:

func FormatErrorText(text string) string {
    return formatErrorTextWithTTY(text, isTTY)
}

func FormatTableHeader(text string) string {
    return formatTableHeaderWithTTY(text, isTTY)
}

And add the corresponding no-op WASM stubs that return text unchanged.

Both new tests (TestFormatTableHeaderWithTTY, TestFormatErrorTextWithTTY) inject a fake ttyCheck directly into the unexported formatXxxWithTTY helpers. They do not call the exported FormatTableHeaderStderr or FormatErrorTextStderr even once.

The only thing the tests verify is that applyStyleWithTTY works when given any arbitrary TTY function. They do not verify that the public API delegates to isStderrTTY rather than isTTY. If someone accidentally wrote:

func FormatTableHeaderStderr(text string) string {
    return formatTableHeaderWithTTY(text, isTTY)  // wrong TTY function
}

...the tests would still pass, and stderr output would silently use stdout TTY detection.

Suggested fix — add lightweight entrypoint tests that exercise the real functions, for example:

func TestFormatTableHeaderStderr_NonTTY(t *testing.T) {
    // isStderrTTY returns false in a CI environment
    got := FormatTableHeaderStderr("Header")
    if got != "Header" {
        t.Fatalf("FormatTableHeaderStderr() = %q; want plain text in non-TTY env", got)
    }
}

func TestFormatErrorTextStderr_NonTTY(t *testing.T) {
    got := FormatErrorTextStderr("boom")
    if got != "boom" {
        t.Fatalf("FormatErrorTextStderr() = %q; want plain text in non-TTY env", got)
    }
}

These work because CI never has a real TTY on stderr, guaranteeing the non-TTY path without mocking.

The old code:

workflowName = styles.Error.Render("✗ ") + styles.Error.Render(stats.Workflow)

The new code:

workflowName = console.FormatErrorTextStderr("✗ " + stats.Workflow)

lipgloss.Style.Render on a multi-word string can behave differently from two separate renders when the style carries Width, MaxWidth, Padding, or Margin properties, because those layout directives apply to the rendered block as a whole. With today's styles.Error (bold + foreground only), the output is identical. But this is now fragile: any future addition of layout properties to styles.Error will silently produce truncated or misaligned output for this combined string without a compile-time signal.

The PR description even calls out the old approach as a pattern to replace, but the behavioral equivalence is style-configuration-dependent — it should be noted as an assumption rather than treated as a safe automatic substitution.

If you want to keep the single-call form, add a comment:

// styles.Error carries no layout properties, so a single Render is equivalent
// to the former two-call approach.
workflowName = console.FormatErrorTextStderr("✗ " + stats.Workflow)