fix(monitoring,groups,caddy): role/os policy filtering, group policy assignment display, and contacts redirect

[mvthul]

Why

• When evaluating configuration policies for monitoring settings on a device, roleFilter and osFilter criteria on policy assignments were not evaluated, which could cause a policy targeted at a different OS/role to win over the appropriate policy.
• The Device Groups list did not display active configuration policy assignments for groups, and bulk policy assignment used an obsolete endpoint.
• Direct navigation to /partner/customers/* and /organizations led to 404s instead of redirecting to the settings organizations views.

What

• Filter candidate monitoring policy assignment rows by device roleFilter and osFilter before picking the highest priority winner in apps/api/src/routes/agents/helpers.ts.
• Join and return assigned policy on DeviceGroup responses in apps/api/src/routes/groups.ts.
• Update apps/web/src/components/devices/DeviceGroupsPage.tsx to fetch configuration policies and apply assignments via /configuration-policies/:id/assignments.
• Add Caddy redirect rules in docker/Caddyfile.prod for /partner/customers/* and /organizations to /settings/organizations.

Requested in discussion #5797.

[ToddHebebrand]

Thanks — both product claims check out, and the monitoring one is a real gap worth landing.

Verified: resolveDeviceEventLogSettings and resolvePolicyMonitoringSettings in apps/api/src/routes/agents/helpers.ts were the only assignment resolvers with no role/OS gate; services/featureConfigResolver.ts:134 (buildRoleOsFilterConditions) and services/configurationPolicy.ts:2204 already apply it. Partner-wide fan-out is preserved (policyOwnershipCondition untouched). /device-groups/bulk really has no route in groups.ts, so that call was dead. Tenancy on the new groups.ts query is fine (existing org-isolation and partner-wide SELECT policies cover it, and groupIds are pre-scoped).

Must-fix

1. Reuse the canonical filter instead of re-implementing it. The new inline predicate treats roleFilter.length === 0 as match-all, while the SQL form in buildRoleOsFilterConditions (IS NULL OR x = ANY(...)) treats an empty array as match-none. Two resolvers disagreeing on the same row is how this bug happened in the first place. Please call the shared helper (or extract a pure matchesRoleOsFilter from it and use it in both places) so there is one definition.
2. Tests. helpers.eventLogDefaults.test.ts and its siblings exist; add cases where an assignment with a non-matching osFilter loses to a matching one, and one for the empty-array semantics you settle on. The new groups.ts policy read has no route test either.
3. Split the Caddy change into its own PR. The directives are fine as written (redir sorts before handle in Caddy's default order, so they do fire), but /partner/customers/* does not exist as a route on main, so the redirects are fork-specific. The /organizations → /settings/organizations one is the part I want to look at separately: /organizations/[id] is live upstream and there is an account-board page planned at bare /organizations, so a permanent-ish redirect there would collide with it. A standalone PR with a sentence on what your fork routes look like will make that quick to decide.

Nice-to-have

• groups.ts mapGroupRow emits policyId, policyName and policy for the same thing; pick one.
• groups.ts orders assignments by priority with no createdAt tiebreak, so two equal-priority rows can flip between reads; the canonical resolver breaks the tie.
• Showing a single group-level assignment as "the policy" mislabels effective config when a device/site/org assignment overrides it; "group assignment" is the honest label.
• DeviceGroupsPage.tsx bulk apply uses Promise.all with priority: 0 hardcoded; a retry after partial success hits the unique constraint and reads as a blanket failure. Consider allSettled and surfacing per-group results.

CI is approved and running. Happy to re-review quickly once the API side is updated.