fix(studio): report advisorCategory consistently across advisor telemetry surfaces (#49746)

<!-- ccr-slack-attribution -->
_Requested by **Pam Chia** · [Slack
thread](https://supabase.slack.com/archives/C076KTY11DF/p1788139328573799?thread_ts=1788139328.573799&cid=C076KTY11DF)_

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Bug fix (telemetry correctness). No user-visible change.

## What is the current behavior?

Linear:
[GROWTH-1153](https://linear.app/supabase/issue/GROWTH-1153/telemetry-advisorcategory-omitted-for-health-lints-on-two-of-five)

**Before:** five surfaces emit the optional `advisorCategory` property
on `advisor_detail_opened` and `advisor_assistant_button_clicked`, and
they disagree about how to derive it. Three pass the lint's category
straight through as `categories[0]`. Two compute it with a hardcoded
ladder — `categories.includes('SECURITY') ? 'SECURITY' :
categories.includes('PERFORMANCE') ? 'PERFORMANCE' : undefined` — which
predates the `HEALTH` category and falls through to `undefined` for
anything it does not name. Because the property is optional, those two
surfaces ship the event with `advisorCategory` silently absent: no type
error, no runtime error, just a hole in the data. A reader querying a
category breakdown of either event gets numbers that depend on which
surface the user happened to click, and `HEALTH` is under-counted. The
split is clearest in `AdvisorSection.tsx`, where a single advisor card
emits both events — the card click through the ladder (L83) and the
Assistant button through the pass-through (L206) — so one card can
report two different categories for the same lint.

The cause is that `AdvisorCategory` in
`packages/common/telemetry-constants.ts` is schema-derived:

```ts
type AdvisorCategory =
  components['schemas']['GetProjectLintsResponse'][number]['categories'][number]
```

The API-types regeneration in supabase/supabase #49646 (merged
2026-08-27, `26e89b36c349893540f8efbd45613921be0a4d18`) widened
`categories` from `('PERFORMANCE' | 'SECURITY')[]` to `('PERFORMANCE' |
'SECURITY' | 'HEALTH')[]`. `AdvisorCategory` picked up the third value
incidentally and the two ladders were never updated — a union widening
is invisible to a hardcoded ladder, so nothing broke loudly.

| Event | Surface | HEALTH behavior before |
| --- | --- | --- |
| `advisor_detail_opened` |
`apps/studio/components/ui/AdvisorPanel/AdvisorPanel.tsx` (L203) |
ladder → property absent |
| `advisor_detail_opened` |
`apps/studio/components/interfaces/ProjectHome/AdvisorSection.tsx` (L83)
| ladder → property absent |
| `advisor_detail_opened` |
`apps/studio/components/interfaces/Linter/LinterDataGrid.tsx` (L163) |
pass-through → `'HEALTH'` |
| `advisor_assistant_button_clicked` |
`apps/studio/components/interfaces/Linter/LintDetail.tsx` (L38) |
pass-through → `'HEALTH'` |
| `advisor_assistant_button_clicked` |
`apps/studio/components/interfaces/ProjectHome/AdvisorSection.tsx`
(L206) | pass-through → `'HEALTH'` |

The two `advisorCategory` property doc comments in
`telemetry-constants.ts` (L2949, L2980) also still read "Category of the
advisor (SECURITY or PERFORMANCE)", which the widening made false.

## What is the new behavior?

**After:** all five surfaces derive `advisorCategory` the same way, so a
category breakdown of these two events is consistent regardless of which
surface produced the event, and `HEALTH` is reported wherever it can
occur. The two ladder sites now read `item.original.categories[0]`,
matching the three sites that already did. The `signal` branch (which
reports `'SECURITY'`) and the `notification` branch (`undefined`) of
those two expressions are unchanged, so nothing about non-lint advisor
items moves. The stale parenthetical is cut from both doc comments.

Net diff is 3 files, -12/+4 lines. No behavior change outside the value
of one optional telemetry property.

## Additional context

**How.** The fix is the pass-through, not an extended ladder. Per the
two options considered:

1. **No lint carries more than one category in practice.** Every lint
fixture in `apps/studio` uses a single-element array (`['SECURITY']`,
`['PERFORMANCE']`). The API type permits a multi-element array, but
nothing in the repo produces one, so the ladder's
SECURITY-over-PERFORMANCE priority is not load-bearing.
2. **The advisors UI already treats the first element as canonical** —
`LinterDataGrid.tsx` L196 renders `<LintCategoryBadge
category={selectedLint.categories[0]} />`.
3. **Extending the ladder would not actually produce agreement.** In the
one reachable multi-category case, a ladder with a `HEALTH` branch
appended still reports the higher-priority category while the three
pass-through sites report `categories[0]`. Only `categories[0]` makes
all five agree, which is the point of the change.

**Reviewers should look at this first — how much data is actually
affected.** Narrower than the headline suggests, and worth stating
precisely. Every surface feeding these events filters lints upstream by
category, and all three filters still admit only `SECURITY` or
`PERFORMANCE`:

- `AdvisorPanel.utils.ts` `createAdvisorLintItems` drops any lint that
resolves to no tab (`if (!tab) return null`), and it is the item source
for **both** ladder surfaces
- `pages/project/[ref]/advisors/security.tsx` filters
`categories.includes('SECURITY')`
- `pages/project/[ref]/advisors/performance.tsx` filters
`categories.includes('PERFORMANCE')`

So a HEALTH-**only** lint is not surfaced anywhere in Studio today and
cannot currently reach any of the five emit sites. The divergence
reachable today is a lint carrying `HEALTH` alongside another category:
it passes the filters, and then the ladder sites and the pass-through
sites disagree. The HEALTH-only omission is latent, and becomes live
data loss the moment HEALTH lints are surfaced — presumably the point of
the API adding the category. Practical consequence: **no backfill or
historical-data caveat is needed**, because no HEALTH-only event was
ever emitted. This is a correctness fix that gets the emit surfaces
right ahead of the category being shown, not a response to an active
data incident.

**How it was tested.** Honest caveat up front: `pnpm install` cannot
complete in this sandbox, so the Studio-scoped checks could not be run
here. `apps/studio` depends on `@std/path` → `npm:@jsr/std__path`, and
the JSR registry is network-blocked in this environment (`GET
https://npm.jsr.io/~/11/@jsr/std__path/1.0.8.tgz` → `403`, both direct
and proxied; `registry.npmjs.org` returns `200`, so it is JSR
specifically). CI on this PR is the real signal for Studio lint,
typecheck, and tests. What did run clean:

- `prettier --config prettier.config.mjs --check` on all three changed
files — clean
- `tsc --noEmit` in `packages/common` (installed via `pnpm install
--filter=common...`) — clean, and `--listFiles` confirms it genuinely
covers both `telemetry-constants.ts` and the widened
`packages/api-types/types/platform.d.ts`
- the changed expression typechecked in a standalone harness against the
real generated `components['schemas']['GetProjectLintsResponse']`,
confirming `categories[0]` is assignable to `AdvisorCategory |
undefined` — with a negative control that correctly errored (`Type
'"HEALTH"' is not assignable to type '"PERFORMANCE" | "SECURITY" |
undefined'`) to prove the harness had teeth

No tests are added. There is no existing test coverage of
`handleItemClick` / `handleCardClick` in either ladder component, and
the change is a narrowing of one expression to match three existing call
sites rather than new logic. Asserting an emitted property value would
require standing up component tests for two components that have none,
which is a larger piece of work than this fix and better done as its own
change.

**Suggested follow-up, deliberately not in this PR.**
`createAdvisorLintItems` and the two advisors pages filter HEALTH lints
out entirely, so the category the API now returns is invisible in
Studio. Whether to surface it is a product decision about a new advisor
category, not a telemetry fix. Also out of scope by request:
`Linter.utils.tsx` badge styling (HEALTH falling back to PERFORMANCE's
badge is harmless).

---
_Generated by [Claude
Code](https://claude.ai/code/session_01Xwj2SotnaHByjbTfqF4Kdm)_

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com>

apps/studio/components/interfaces/ProjectHome/AdvisorSection.tsx

@@ -82,11 +82,7 @@ export const AdvisorSection = ({ showEmptyState = false }: { showEmptyState?: bo
 
       const advisorCategory =
         item.source === 'lint'
-          ? item.original.categories.includes('SECURITY')
-            ? 'SECURITY'
-            : item.original.categories.includes('PERFORMANCE')
-              ? 'PERFORMANCE'
-              : undefined
+          ? item.original.categories[0]
           : item.source === 'signal'
             ? 'SECURITY'
             : undefined

apps/studio/components/ui/AdvisorPanel/AdvisorPanel.tsx

@@ -202,11 +202,7 @@ export const AdvisorPanel = () => {
 
     const advisorCategory =
       item.source === 'lint'
-        ? item.original.categories.includes('SECURITY')
-          ? 'SECURITY'
-          : item.original.categories.includes('PERFORMANCE')
-            ? 'PERFORMANCE'
-            : undefined
+        ? item.original.categories[0]
         : item.source === 'signal'
           ? 'SECURITY'
           : undefined

packages/common/telemetry-constants.ts

@@ -2959,7 +2959,7 @@ export interface AdvisorDetailOpenedEvent {
      */
     advisorSource: 'lint' | 'notification' | 'signal'
     /**
-     * Category of the advisor (SECURITY or PERFORMANCE)
+     * Category of the advisor
      */
     advisorCategory?: AdvisorCategory
     /**
@@ -2990,7 +2990,7 @@ export interface AdvisorAssistantButtonClickedEvent {
      */
     origin: 'homepage' | 'lint_detail'
     /**
-     * Category of the advisor (SECURITY or PERFORMANCE)
+     * Category of the advisor
      */
     advisorCategory?: AdvisorCategory
     /**