Fix opslevel_filter nil-pointer panic reading case_sensitive when API…

[saditya370]

Resolves OpsLevel ticket #15041. Re-lands approved PR #653 (closed by the reporter after they worked around it locally, so the fix was never merged).

Problem

terraform plan panics with a nil-pointer dereference when reading any opslevel_filter whose Terraform state holds a case_sensitive (or case_insensitive) value for a predicate that the OpsLevel API returns as nil — e.g. exists, matches against an ID, and other predicate types that don't take a case-sensitivity argument.

NewFilterResourceModel only checked whether state had a value, then unconditionally dereferenced the API predicate's CaseSensitive (*bool). For predicate types with no case sensitivity the API returns nil, so the deref panics. This blocks all filter operations for workspaces upgrading from provider 0.8.x, whose schema stored case_sensitive on every predicate regardless of type — the first terraform plan after upgrade crashes.

Solution

Guard both branches with opslevelPredicate.CaseSensitive != nil. When the API returns nil, the field normalizes to types.BoolNull() (unset), which is correct: nil from the API means the predicate type has no case-sensitivity concept. This mirrors the guard already present in ExtractFilterPredicateModel, and state converges to null with no perpetual drift (config can't set case_sensitive on those types anyway — the SDK's validateCaseSensitivity rejects it).

Added regression tests covering: state has case_sensitive + API returns nil (must not crash, result null); the symmetric case_insensitive branch; the happy path where the API sets the value (preserved); and fresh import with a nil API value. The crash test panics at resource_opslevel_filter.go:116 before the fix and passes after.

Checklist

• I have run this code, and it appears to resolve the stated issue.
• This PR does not reduce total test coverage
• This PR has no user interface changes or has already received approval from product management to change the interface.
• Make a changie entry that explains the customer facing outcome of this change