feat(meetings): handle meetings that predate invite-response tracking #3263

Requirements: FR-026, SC-005 in specs/011-meeting-details-redesign/requirements.md. State model: state-matrix.md in the same directory.
Branch: PRs for this issue target the integration branch feat/meeting-details-v2, not main. Nothing in this epic reaches production until the release PR #3249 merges.

Design: https://claude.ai/design/p/c70cdcac-911f-4337-9d87-3daed9d85f58?file=Meeting+Details.dc.html&via=share

Prototype settings panel: time / viewer / privacy / rsvpTracking / pastAccess / myRsvp / recur / via / pageStatus. Its look and feel differs from the current app on purpose — follow it.

Epic: #1765 · Meetings v2 epic: #1451 · Plan ID: N-01 · Size: S · Depends on: E0-02

Delivery: this ships as part of meeting details V2, side by side with the existing page, behind MEETING_V2_ENABLED_FLAG. Do not modify, refactor or delete the existing meeting details page. V1 stays fully functional and is what untargeted users see. Parent: Meetings v2 epic #1451. Full rules in #1765.
Components: follow the prototype for design, but build it from the existing lfx-* components in app/shared/components/. Extend a wrapper before forking it; create a new component only when the design can't be expressed otherwise, and say so in the PR.

Problem. Meeting.is_invite_responses_enabled is true only for meetings created after the January 2024 invite-responses release. For everything older, the shipped code (GH-1951) hides all RSVP UI — but it hides it silently, leaving empty containers and, in the action rail, a genuine dead end: branch 3 is @if (effectivelyInvited() && inviteResponsesEnabled()) with no @else, so an invited user on a pre-2024 meeting who cannot register sees nothing at all.

Scope. Design and implement the explicit state:

• Action rail: the rsvp-unavailable slot kind from E2-01, with copy that says RSVP isn't tracked for this meeting rather than rendering an empty box.
• Status pill: time-state variant only, never Awaiting your RSVP (E1-05).
• People section: invitee count only — no tallies, no roster RSVP filter, no per-avatar status badge.
• Everywhere the gate is read, use the normalized is_invite_responses_enabled. Never read the raw indexed alias use_new_invite_email_address; the BFF normalizes one onto the other.

Acceptance criteria

• isMeetingInviteResponsesEnabled(meeting) used everywhere; strict === true, missing ⇒ hide.
• No empty container anywhere in the off-state — every hidden block either collapses fully or explains itself.
• Every new counting call site passes { inviteResponsesEnabled } to getRegistrantAttendanceStatus / countRegistrantAttendance. Omitting it over-reports acceptances, because a calendar-invite acceptance is not an LFX RSVP.
• Added to E0-01's matrix as axis F, not a footnote.
• Unit coverage for the off-state in the existing join-page spec.

Filed from meeting-details-redesign-implementation-plan.md (revised 2026-09-23).