Make field-prefix highlighting order-independent (longest match wins)

[jonathandeamer]

Follow-up to #6 / #19.

highlightFields (render/fields.go) matches the first fieldPrefixes entry that strings.HasPrefix-matches a line, in slice declaration order. Today that's fine — no current entry is a prefix of another (the colons separate them) — but it's a latent footgun: which label gets highlighted silently depends on humans ordering the slice so a longer, more-specific label is never shadowed by a shorter one declared earlier.

Task

Make matching longest-prefix-wins, independent of declaration order — e.g. sort the combined generic + host-extra prefixes by descending length once and match against that. As a bonus this lets the two near-identical match loops in highlightFields (one for fieldPrefixes, one for extra) collapse into one.

While restructuring the list, also add brief grouping comments — the set is getting long and mixes BSD vs GNU label forms (Login:/Login name:, Name:/In real life:), Label: fields, trailing-value markers (Last login, Mail last read), and standalone status sentences (No mail., No Plan.). A couple of one-line group headers help the next contributor know where a new label belongs. (Group comments are now declaration-order-independent thanks to longest-match, so they're free to organize for readability.)

Defensive / maintainability work, not a current-bug fix.

Acceptance criteria

• Matching no longer depends on slice order (a test with an overlapping short/long prefix pair proves the longer wins regardless of order).
• The duplicated generic/extra match loops are unified.
• Host-extra prefixes (e.g. tilde.team's Pronouns:) still participate in the same ordering.
• fieldPrefixes has brief grouping comments.
• Existing goldens unchanged; make check green.