fix: render tags-input infolist entries as badges

[ManukMinasyan]

Summary

MultiChoiceEntry is used by both checkbox-list and tags-input. It renders the field's predefined options as a checkbox list and marks options whose ID appears in the stored selection. tags-input calls ->withArbitraryValues(), so its stored values are raw user-typed strings, not option IDs — the in_array($optionId, $selected, false) check never matches and the user's actual tags don't render. The result is what the linked issue shows: tags-input fields appear as an unchecked checkbox list of suggestions instead of the tags the user entered.

The table column path (MultiChoiceColumn → LookupMultiValueResolver → LookupResolver) already special-cases acceptsArbitraryValues and renders the stored strings as badges, which is why the list view works. This PR brings the infolist entry in line with that behavior.

Change

MultiChoiceEntry::make() now branches on \$customField->typeData->acceptsArbitraryValues:

• Arbitrary-value fields (tags-input) → return a TextEntry with the stored strings resolved via LookupMultiValueResolver and rendered as badges via the existing ConfiguresBadgeColors trait (which already handles the tags-vs-options color logic).
• Option-backed fields (checkbox-list) → unchanged checkbox-list view rendering.

No new dependencies, no API changes, no new view files — the fix reuses pieces that already exist in the codebase.

Test plan

• New tests/Feature/Filament/Components/MultiChoiceEntryTest.php covers both branches (asserts ViewEntry for checkbox-list, TextEntry + isBadge() for tags-input). Verified the test fails on 3.x without this fix.
• vendor/bin/pest --parallel — 656 passed, 3 todos, 0 failed.
• vendor/bin/pint --test — passed.
• vendor/bin/rector --dry-run — clean.
• vendor/bin/phpstan analyse — no errors.
• vendor/bin/pest --type-coverage --min=100.0 — 100% maintained.
• Manual: created a tags-input field on an app's Company model, saved tag values, called MultiChoiceEntry::make() and confirmed the returned entry is TextEntry with isBadge() === true; checkbox-list still returns the ViewEntry with custom-fields::infolists.checkbox-list-entry.

Closes

Fixes relaticle/relaticle#281

[Copilot]

Pull request overview

This PR fixes how tags-input custom fields render in Filament infolist entries by aligning MultiChoiceEntry behavior with the existing table column logic for arbitrary-value multi-choice fields. Instead of rendering a checkbox-list of suggested options (which never matches raw user-entered tag strings), the infolist now renders the stored tag strings as badge text entries.

Changes:

• Add an acceptsArbitraryValues branch in MultiChoiceEntry::make() to render tags-input as a badge TextEntry using LookupMultiValueResolver.
• Keep the existing checkbox-list ViewEntry rendering unchanged for option-backed multi-choice fields.
• Add a feature test covering both branches (checkbox-list vs tags-input).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Filament/Integration/Components/Infolists/MultiChoiceEntry.php	Branches infolist rendering: tags-input uses resolver-backed badge TextEntry; option-backed fields keep the existing checkbox-list ViewEntry.
tests/Feature/Filament/Components/MultiChoiceEntryTest.php	Adds coverage to ensure the correct entry type is returned for both option-backed and arbitrary-value multi-choice fields.