TUI: update-batch warnings from successful updates are still unreadable when the ResultLines overlay wins

[dyoung522]

Summary

Residual gap deliberately left out of #253 (PR #258), recorded so it isn't rediscovered.

#253 auto-opens a "warnings" overlay when a buildAction-routed outcome carries 2+ warnings. But when an outcome carries both ResultLines and 2+ Warnings — today only the apply-updates batch (applyUpdatesSequentially, internal/tui/mutations.go) can — the pre-existing "update results" overlay keeps priority (via the m.overlay == nil guard in app.go's actionDoneMsg handler, pinned by TestActionDoneResultLinesKeepPriorityOverWarningsOverlay), and the warnings overlay defers to it.

The batch's ResultLines carry per-update ✗ failure lines, so failures are readable. What is not: warnings emitted by successful updates — applyUpdatesSequentially folds each successful ApplyUpdate's outcome.Warnings into the aggregate Warnings slice, but the update's ResultLines entry is just ✓ <name> <from> → <to>. On a merged-pak game (Icarus), applying an update that triggers a recompile can emit ≥2 merge-time asset-conflict warnings: the status line reads Applied 1 update(s) (2 warnings), the "update results" overlay shows only the ✓ line, and the warning text is unreachable — exactly #253's failure mode, surviving in the one flow whose outcome shape predates it.

Possible directions (not settled)

• Append the aggregate warnings to the update-results overlay's lines (e.g. a blank separator + one line per warning), keeping a single overlay.
• Or interleave each update's warnings under its own ✓ line in ResultLines at batch time.

Either touches the update-results overlay's designed content, which is why it was split out of #253's rendering fix rather than bundled in.

[dyoung522]

Fixed in #265, merged to develop as 7b11636. Manual TUI smoke test passed. Ships with the next release batch.

Direction A, applied at batch time: applyUpdatesSequentially now appends success-emitted warnings to ResultLines as a trailing section (blank separator, then one line per distinct warning), so the update-results overlay that wins the priority contest already carries them.

The premise this rested on was verified rather than assumed: these are profile-level merge diagnostics (ApplyMergedPakRegen's warnings come solely from syncMergedPak), so interleaving them under an individual update's ✓ line would have misattributed a cross-mod conflict to one mod. Exact-text dedupe applied to both the section and the aggregate Warnings, so the one-row (N warnings) count matches what the overlay shows — a multi-update batch re-runs the merge per update and would otherwise repeat the same text once per update.

TestActionDoneResultLinesKeepPriorityOverWarningsOverlay passes unchanged — the deferral it pins is now lossless rather than lossy, so the assertion still means what it meant. The comment at the guard in app.go was extended to say why; that is the only app.go change, and the overlay-priority logic itself is untouched.

Verified independently on the merged head: go build && go vet && gofmt -l && go test ./... all clean, and app.go's diff is comment-only.