TUI bulk-edit: polish the form, expose custom fields individually, make tags a dropdown

[thomaschristory]

The TUI bulk-edit form (nsc/tui/screens/bulk_edit_form.py) lags behind the
polished single-record editing UX. Three related problems:

1. The bulk-edit form is visually rough

It's a flat stack of Horizontal rows (an include-toggle Switch + a widget per
field) and doesn't match the cleaner single-edit experience. We should give it the
same polish we applied to single editing (the detail-view inline editing in
nsc/tui/screens/detail.py) — consistent layout, alignment, grouping, and clear
affordance for which fields are opted into the bulk set.

2. Custom fields can't be set one by one

Custom fields appear as a single opaque field (one input for the whole
custom_fields object) rather than one widget per custom field. field_to_widget
(nsc/tui/forms.py:39-56) has no special-casing for custom_fields, so it falls
through to a generic text widget. We already expanded custom_fields into
individual columns (#118/#121); editing should do the same — expand into one
typed widget per custom field (text/number/select/switch per the field's type and
choices). This relates to #132 (showing each custom field's label) and #133
(nice value rendering) — they share the need to read custom-field definitions
(GET /api/extras/custom-fields/, scoped to the object type).

3. Tags should be a dropdown, not free text

tags renders as a free-text Input. It should be a multi-select dropdown
populated from the available tags (GET /api/extras/tags/), so the user picks from
existing tags instead of hand-typing names/slugs. (NetBox tags are an M2M; the
widget needs to support selecting multiple.)

Where the work lives

• nsc/tui/screens/bulk_edit_form.py — layout/polish + include-toggle UX.
• nsc/tui/forms.py — field_to_widget / WidgetSpec / WidgetKind: add a
  custom-fields expansion and a tags (multi-select) widget kind. This is the shared
  layer, so changes here also reach the single EditForm
  (nsc/tui/screens/edit_form.py) and the detail-view inline edit — which is good:
  the same improvements (per-field custom fields, tags dropdown) should apply to
  single editing too, for consistency.
• New widget(s): a multi-select for tags; likely a new WidgetKind.
• Data sources to fetch + cache (mirror the object-type resolver from feat(saved-searches): back saved searches with NetBox native SavedFilter #130):
  /api/extras/tags/ and /api/extras/custom-fields/ (filtered by object type).

Considerations / open questions

• Bulk semantics for M2M tags: setting tags in bulk — does it replace the tag
  set on every selected record, or add? NetBox bulk PATCH replaces. Make the
  behavior explicit in the UI (e.g. label it "Set tags to…").
• Custom field include toggles in bulk: each expanded custom field needs its
  own include toggle so users set only the ones they choose.
• Keep the underlying API payload correct: custom fields nest under
  custom_fields.<name>; tags submit as a list of {name}/ids per the schema.
• Graceful degradation if /api/extras/tags/ or /api/extras/custom-fields/ can't
  be fetched (fall back to the current text input rather than erroring).
• Consider splitting into sub-PRs: (a) tags multi-select widget (shared), (b)
  custom-fields per-field widgets (shared), (c) bulk-form layout polish.

[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]

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.