fix(forms): resolve dependent fields via CoreVisibilityLogicService (fixes #149 strict-mode crash)

[crossi-dev]

Fixes #149

What's happening

With Laravel strict mode on (Model::preventAccessingMissingAttributes()), rendering a form throws MissingAttributeException: visibility_conditions. FormBuilder::getDependentFieldCodes() reads $field->visibility_conditions, but that attribute no longer exists on CustomField — visibility moved into settings->visibility and is read through CoreVisibilityLogicService. Without strict mode it fails quietly (the access returns null), and the loop also still expects the old ['field' => ...] shape rather than the current field_code, so dependent-field resolution was silently broken either way.

The change

Route through the service the rest of the codebase already uses:

$service = app(CoreVisibilityLogicService::class);
// ...
$dependentCodes = array_merge($dependentCodes, $service->getDependentFields($field));

getDependentFields() returns the correct array<string> of field codes, so both the strict-mode crash and the shape mismatch disappear in one move.

Verified

PASS  Tests\Feature\Integration\FormBuilderStrictModeTest
 ✓ resolves dependent field codes via CoreVisibilityLogicService
 ✓ does not throw MissingAttributeException under preventAccessingMissingAttributes()

Tests: 694 passed (2647 assertions)

(The 3 pre-existing Dom\HTMLDocument not found failures are a PHP 8.4 DOM-extension thing, unrelated to this change.)

---

Strict mode is getting recommended as a Laravel default now, so this one will bite more people over time — figured it was worth fixing properly rather than just guarding the access. I went with app(CoreVisibilityLogicService::class) to match the call sites right next to it, but a couple of your builders take their collaborators via the constructor — want me to inject it that way instead for consistency? Happy either way.

(I'm with Choreless — we fix and ship code for small teams — but no strings here, I just use Filament a lot.) — Charles