Selected add-on percentage shows overall add-on rate

Objective

1. Align the scheduler table “Selected Add Ons” rate with the same add-on categories the user selects for the add-on panel (global service categories), so the number reflects selected add-ons—not an overall “any add-on” rate.
2. Review and correct close rate (and related) calculations on the Client Care dashboard so reported rates match the intended definitions and stay consistent across surfaces.
3. ALSO, can we make the dropdown list on the add on service categories only show services that are upsellable : true

Background

• On Attik Admin → Client Care Dashboard, users can filter global add-on categories; the main metrics path returns per-category (and combined) add-on rates that depend on those selections.
• Product feedback: for schedulers, the column labeled like selected add-ons is effectively showing a broader add-on signal (overall / any-add-on style), not the rate for the currently selected category set.
• There is also an open need to tighten close-rate math so leadership can trust the dashboard without manual reconciliation.

Scope

Backend — attik-backend

• GET /cc-dashboard/metrics in src/routes/ccDashboard.ts already takes globalCategoryIds, resolves categories and descendant categories against GlobalServiceCategory and ServiceCategoryAssignment, then uses Charge.distinct on _inspectionId scoped to core inspection id lists from the cc_inspection_base view (CC_INSPECTION_BASE_VIEW from src/util/constants/ccDashboard.js). That path is the reference for “selected add-on” semantics.
• GET /cc-dashboard/scheduler-metrics in the same file does not read globalCategoryIds. The aggregation uses view fields such as hasAddon for addonNum / addonDenom, and computeRates exposes that as selectedAddOnRate—so the API name and UI label imply selected categories, while the implementation is category-agnostic unless changed.
• Open-quote handling for close rate on /metrics uses Quote plus primary Charge rows and serviceFlagMap from assignments; /scheduler-metrics has a parallel path (including createdType: 'csr' constraints for open quotes). Any close-rate fixes should preserve parity between KPI / metrics and scheduler breakdowns unless product explicitly diverges.
• The Mongo view is built by scripts/createCcDashboardViews.ts; if category-scoped add-on presence per row is needed at aggregation time, the view or pipeline may need extending—decision needed on whether to push category logic into the view, reuse charge lookups like /metrics, or another approach.

Frontend — attik-frontend

• src/app/admin/client-care-dashboard/CCDashboardClient.tsx loads add-on rates via cc-dashboard/metrics with globalCategoryIds in fetchAddonRates, but loads scheduler data via fetchSchedulerMetrics with only companyIds, startDate, and endDate—no selected category ids—so the UI cannot today drive scheduler add-on rates from the same selection.
• src/app/admin/client-care-dashboard/_components/EmployeeTable.tsx labels the column around selected add-ons and blends selectedAddOnRate across rows using ordersCreated weights in computeSubsetAverage; once the API matches selected categories, confirm the aggregate row still matches the intended definition.
• Types for scheduler rows live in src/app/admin/client-care-dashboard/_types.ts (selectedAddOnRate on SchedulerRow).

References

• Slack context (issue attachment): thread that describes the scheduler “selected add-on” vs overall add-on behavior.
• View pipeline: scripts/createCcDashboardViews.ts and CC_INSPECTION_BASE_VIEW usage in src/routes/ccDashboard.ts.