TUI detail view renders tags (and other list-of-object fields) as a raw dict/list repr

[thomaschristory]

Symptom

Open a device (or any object) detail view in the TUI: the Tags field shows as
a raw Python repr of a list of dicts — e.g. [{'id': 3, 'url': '...', 'display': 'prod', 'name': 'prod', 'slug': 'prod', 'color': '4caf50'}] — instead of a clean
list of tag names (ideally colored, like the list view). The same applies to any
field whose value is a list of objects.

Root cause

nsc/tui/screens/detail.py _value_display (lines 127-147) only special-cases a
single dict (value.get("display")) and has no branch for lists:

• Editable fields (tags are editable) read the raw record value
  (self._record.get(row.name)) and fall through to str(value) → raw list-of-dicts.
• Non-editable fields use flat.get(row.name) but then str(value); with object
  colors on, flat yields a list[ColoredValue], which str() turns back into an
  ugly repr.

Meanwhile the list table already renders this correctly: it goes through
flatten(...) → _displayify (nsc/output/flatten.py:45-65), which turns a tag
list into colored chips or a comma-joined display/name string, and
nsc/tui/view.py:_cell renders ColoredValue/list[ColoredValue] as Rich Text.

So the fix is to make the detail view reuse the same rendering rather than
stringify.

Desired

In the detail view, list-of-object fields (tags, and any similar M2M/list field)
display like the list table: comma-separated display/name values, colored when
object colors are enabled. The display path should reuse _displayify /
flatten / the _cell logic instead of str(value).

Considerations

• _value_display currently returns str; to show colors it would need to return
  str | Text (the DataTable already accepts Text, as the list view shows). If
  we don't want colors in detail yet, at minimum render the comma-joined
  display/name string (no raw dicts).
• Apply to both the editable and non-editable branches — tags are editable, so the
  raw-record branch must also format lists nicely (display only; editing the tag
  set is a separate concern, see below).
• Single dicts already work via display; keep that. Choice fields use label
  (already handled by _displayify).
• Editing: this issue is about display. Inline-editing a tag list is out of
  scope here — the formatted display must not break or be mistaken for an editable
  scalar. If a list field is currently treated as editable-scalar, ensure it shows
  the nice value and editing it doesn't corrupt the list (split into a follow-up if
  needed).

Scope

Affects every detail view (device and all other object types), since the rendering
is generic. Likely a small change centered on detail.py:_value_display plus a
shared helper extracted from view.py/flatten.py.

[thomaschristory]

Claiming for the 1.6.0 milestone. Working all three together on branch feat/tui-custom-fields-tags-1.6.0 (one PR closing #132/#133/#134) — they share a custom-field-definitions resolver (and #134 a tags resolver), mirroring the #130 object-type resolver. Scope: #133 detail-view list rendering, #132 custom-field column labels, #134 bulk-edit polish + per-field custom fields + tags multi-select.

[thomaschristory]

Fixed on feat/tui-custom-fields-tags-1.6.0: detail view now routes list-of-object fields (tags, M2M) through the shared flatten/render_cell pipeline — comma-joined display, colored when object colors are on. Both editable and read-only branches covered.

[thomaschristory]

PR #135 opened (branch feat/tui-custom-fields-tags-1.6.0, milestone 1.6.0). All three issues are implemented and tested there; full suite green (1324 passed). Awaiting CI + review.