make views orientation sensitive

[plastikfan]

Views should change the presentation of their content depending on the window orientation, that is to say, when the window dimension changes the current layout may not be best best for the current content as severe truncation of fields may result. For example the highway view, can become too cramped if the window orientation is portrait, mainly due to insufficient space to render the path and the landing strip on the same line. So in this case, instead of using just a single text row to render each worker, we could use 2 rows per worker and present fields accordingly.

[plastikfan]

Responsive Layout: Highway and Porthole Views

Context

The highway and porthole views are both Bubble Tea views rendered in the
terminal. Both views must adapt their layout in response to terminal window
dimension changes (tea.WindowSizeMsg).

The linear view is out of scope for this task.

---

Problem

When the terminal window is in a portrait orientation (narrow width, tall
height), the current fixed single-row-per-worker layout in the highway view
becomes too cramped. Fields such as the path and the landing strip cannot share
a single line without severe truncation.

The same class of problem applies to the porthole view, where content regions
may also be poorly proportioned for portrait orientations.

---

Goal

Implement orientation-aware responsive layout for both the highway and
porthole views. The layout strategy must switch automatically when the window
dimensions cross a defined threshold between landscape and portrait orientation.

---

Decisions

The following design questions have been resolved and must be treated as
fixed constraints during implementation.

#	Question	Decision
1	Orientation threshold rule	Portrait when width < height; Landscape otherwise
2	Porthole portrait regions	Flags line, header line, and each tree node - see section 4
3	Worker separator in highway portrait layout	No extra horizontal rules; use blank lines only, revisit after visual review
4	Shared orientation helper location	prism/layout package

---

Requirements

1. Orientation Detection

• Define an orientation type with two values: Landscape and Portrait.
• Derive the current orientation from the window dimensions received in
  tea.WindowSizeMsg:
  • Portrait when width < height
  • Landscape otherwise
• Expose a helper in the prism/layout package:
  func Orientation(width, height int) ViewOrientation
• Neither the highway model nor the porthole model may contain raw
  width < height comparisons inline; all callers must go through this helper.

2. Highway View - Landscape Layout (current behaviour)

• One row per worker.
• All fields for a worker rendered on a single line.

3. Highway View - Portrait Layout (new behaviour)

• Multiple rows per worker, expanding to as many lines as the fields require.
• Field order in portrait layout must match the left-to-right field order of
  the landscape layout - no reordering.
• The first field of a worker occupies its own line as in landscape.
• Each subsequent field that cannot fit on the first line is placed on its own
  line with:
  • A leading dot punctuation character consistent with the dot used for
    action and pipeline name separators elsewhere in the UI.
  • An indent of one additional level relative to the first field to signal
    that the lines are subordinate to it.
• When the window widens back past the threshold, the layout folds back to
  the landscape single-line presentation automatically.
• No extra horizontal rule separators between workers. Blank lines are
  sufficient; re-evaluate after a visual review of the running output.

4. Porthole View - Portrait Layout (new behaviour)

The following regions of the porthole view require portrait variants. Field
order and the dot-plus-indent continuation convention from section 3 apply
equally here.

4a. Flags Line

• In landscape, all active flags are rendered on a single line.
• In portrait, the flags line expands to use as many lines as required to
  avoid truncation, then collapses back to a single line when the window
  widens.

4b. Header Line

• In landscape, the header is a single line.
• In portrait, the header expands in the same way as the flags line,
  splitting fields across additional lines as required using the dot-plus-indent
  continuation convention.

4c. Tree Node Representation

• In landscape, each node is a single line containing all fields.
• In portrait, each node expands across multiple lines. The split must be
  applied consistently across both the highway view and the porthole view -
  the same fields must break at the same points in both views.
• Specifically:
  • The full path is split into two parts: the parent directory path on one
    line and the file name on the next continuation line.
  • The action is placed on its own continuation line.
  • The landing strip is placed on its own continuation line.
• Continuation lines use the dot-plus-indent convention: a leading dot
  character and one additional level of indent relative to the opening line of
  the node.

4d. Scrollbar

• The scrollbar must be recalculated to account for the increased line count
  per node when in portrait layout.
• The scrollbar height and thumb position must remain accurate relative to the
  actual rendered line count, not the node count.

5. Layout Strategy Encapsulation

• All orientation detection and layout selection logic lives in prism/layout.
• Layout variants must be named types, not bare boolean flags.
• View() renders only; all layout decisions are made in Update() on receipt
  of tea.WindowSizeMsg.

6. Window Resize Handling

• Both views store Width and Height on the model.
• On each tea.WindowSizeMsg, recompute the orientation via the layout
  helper and update the active layout strategy before the next View() call.

---

Constraints

• No changes to the linear view.
• The orientation threshold (width < height) is defined in exactly one place
  in prism/layout; no other file may duplicate it.
• The dot-plus-indent continuation convention must be visually consistent
  across the highway and porthole views.
• Field split points for tree nodes must be identical in both views.
• All new types must follow existing naming conventions in the prism package.
• Portrait and landscape layout paths must both be covered by tests.