Log viewer retains only the newest 1000 lines — early cf push output is unrecoverable in the UI

[nabramovitz]

Current behavior

The shared LogViewerComponent behaves as a proper circular buffer: it retains the newest maxLogLines = 1000 rendered lines (src/frontend/packages/core/src/shared/components/log-viewer/log-viewer.component.ts:89), evicting the oldest DOM node as new output arrives (binElement() removes firstChild, ~lines 362-370; hold-at-cap behavior is covered by log-viewer.component.spec.ts:86-101). Collection never stops — long streams display live output indefinitely.

Both the app Log Stream tab and the Deploy Application (cf push) step 3 panel render through this component, so both inherit the 1000-line rolling window. The backends are pure uncapped relays in both paths (src/jetstream/plugins/cloudfoundry/cf_websocket_streams.go tail/firehose handlers; src/jetstream/plugins/cfapppush/deploy.go SocketWriter.Write), so the truncation is purely client-side rendering.

Problem

1000 lines is a small window and it is not configurable. For a cf push, the earliest output (staging/buildpack detection, the first error of a failed staging) frequently scrolls out of the retained window before the push finishes, and there is no way to get it back in the UI even though the backend streamed every line.

Proposed direction (for discussion)

• Make the retention window configurable and/or raise the default for the deploy panel.
• And/or keep the full received text in a lightweight string buffer behind a "download full log" affordance, independent of the 1000-line DOM window (the DOM cap exists for render performance and can stay).

Found while verifying that the log paths behave as circular buffers — they do; this issue is about the window size and the unrecoverable early lines, not the ring semantics.

[nabramovitz]

Decided direction

Make the circular window size user-settable, clamped to a floor and ceiling:

• maxLogLines becomes a user preference rather than a hard-coded constant. The component keeps 1000 as the default when no preference is set.
• The setting is clamped in one place when read: a minimum it can never drop below (so the viewer always retains a usable amount of context and the eviction logic never degenerates), and a maximum cap (the DOM window exists for render performance; an unbounded value would defeat it). Proposed starting bounds for discussion: min 100, max 10,000.
• Both consumers inherit it automatically since they share LogViewerComponent (app Log Stream tab, Deploy Application step 3).
• Ring semantics are unchanged: evict-oldest, never stop appending — only the window size becomes adjustable.

Out of scope for this issue: the "download full log" affordance mentioned above can be a separate follow-up if the sized window proves insufficient for failed-staging diagnosis.