fix(settings): clear default_model when provider_deny_list blocks it

[kilo-code-bot]

Summary

• Fixes a bug where updating only provider_deny_list could leave a now-blocked default_model persisted in org settings.
• Previously, the revalidation guard only fired when model_deny_list was included in the update and non-empty, so a provider-only deny-list update that blocked every provider for the current default model would silently leave the stale value in the DB.
• The fix checks both deny lists: the guard now triggers when either model_deny_list or provider_deny_list is part of the update, and uses the effective (post-update) values of both lists to evaluate whether default_model is still allowed.

Addresses: #799 (comment)

Verification

• Reviewed the diff and logic manually; the effectiveModelDenyList/effectiveProviderDenyList fallback to [] ensures createAllowPredicateFromDenyList receives the correct post-update state regardless of which list was updated.
• Could not run automated tests (node_modules unavailable in this environment).

Visual Changes

N/A

Reviewer Notes

The inner if (effectiveModelDenyList.length > 0 || effectiveProviderDenyList.length > 0) guard preserves the original behaviour of skipping the async predicate check when both lists are empty (i.e. deny lists are being fully cleared — in that case all models become allowed, so no need to clear default_model).

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (1 files)

• src/routers/organizations/organization-settings-router.ts