Stop advertising $feature_flag_called in taxonomy, autocomplete, and product surfaces #88126

Problem

RFC #1209 moves $feature_flag_called out of the events table. Every insight, cohort, action, and destination built on it before that happens is one more artifact we have to migrate or break.

The scan in the RFC's appendix H puts the current population at roughly 5,700 US and 2,600 EU saved insights on the event, and roughly 1,142 US and 587 EU teams with an artifact that breaks outright. Appendix G found that 39% (US) and 40% (EU) of the human-created insights on this event have not been viewed in 90 days, so people build them faster than they clean them up.

While the event still shows up in taxonomy and autocomplete, that list keeps growing during the exact window we are trying to work through it. Ben asked for this directly in an unresolved thread on #1209: "Here we could also start removing all references to the event from the UI / taxonomy etc so no new uses of it are added." He restated it in #project-data-reduction-feature-flag-properties as fixing the new paths first.

The RFC currently schedules this for phase 2. It should happen now, ahead of routing, because its whole value is the artifacts it prevents.

What is already done

• The Usage tab renders its charts inline and no longer auto-creates a dashboard per flag. POST /api/projects/:id/feature_flags/:id/dashboard/ is API-only (products/feature_flags/backend/api/feature_flag.py, dashboard action).
• The taxonomy entry for $feature_flag_called already carries ignored_in_assistant: true (frontend/src/taxonomy/core-filter-definitions-by-group.json), so Max should already be leaving it out. Worth confirming rather than assuming.

Scope

Work through the surfaces that put the event in front of someone building something new:

• Event taxonomy and the core filter definitions (frontend/src/taxonomy/taxonomy.tsx, frontend/src/taxonomy/core-filter-definitions-by-group.json).
• Event name autocomplete in insight builders, cohort criteria, action definitions, and destination filters.
• Anywhere the event is offered as a suggestion or example.

Three decisions this needs before anyone writes code:

• Everyone, or only routed organizations? Unsettled, and it changes the work. Asked in #project-data-reduction-feature-flag-properties, awaiting an answer. The argument for everyone: new uses come overwhelmingly from existing customers, since that is where the teams are, so hiding it only for new organizations would prevent almost nothing. Hiding also breaks nothing on its own, because existing artifacts keep working and anyone who knows the event name can still type it, so it needs none of the cohorting that routing needs.
• Hide, or hide with an explanation? Silently dropping the event from autocomplete confuses anyone who knows it exists and cannot find it. A short note pointing at posthog.flag_evaluations and the Usage tab is probably better than absence.
• Which mechanism? posthog/api/event_definition.py has a hidden field, but it is Enterprise-only, admin-set per team, and only honored when a caller passes exclude_hidden=true. That is a customer-facing control, not a product-wide one, so this likely needs its own path rather than reusing it.

Out of scope

• Existing saved artifacts. They keep working until routing starts. Migrating them is phase 2 and 3 of the RFC.
• The HogQL alias that re-points existing queries at the new table.
• Anything that changes what SDKs send.

Acceptance criteria

• $feature_flag_called no longer appears in event autocomplete when building an insight, cohort, action, or destination filter.
• Someone searching for it gets a pointer to the Usage tab and posthog.flag_evaluations rather than silence.
• Existing saved artifacts that reference the event continue to render and run unchanged.
• Max does not suggest the event. Confirm the existing ignored_in_assistant flag actually covers this.