Organizer Sidebar Performance: Audit, Plan, Approved HTTP N+1 Fixes, Verification, and Documentation

# Organizer sidebar — remove slow page loads (HTTP N+1 + repeated lookups)

Read first:
- `C:\myworkspace\holidaylandmarks\holidaylanmark\docs\performance\http-calls.md`
- `C:\myworkspace\holidaylandmarks\holidaylanmark\docs\performance\tourists-contact-lookup-pr554-review.md`
  (the pattern to reuse: one list call returns the needed fields instead of one call per row,
  opt-in on the receiving API, fallback to the old per-row call if the field is missing)
- `livewire-hygiene.md` and `CLAUDE.md` in the same folder (do not redo what is already done)
- root `CLAUDE.md`, `holidaylanmark/CLAUDE.md` and the `CLAUDE.md` of every service you touch

Enter Plan Mode first. Do not change anything until I approve the plan.

## Problem
When an organizer clicks these **Organizer sidebar** items, Livewire's blue wire:navigate progress
bar shows, so the server is slow to answer:
My Profile · Trip Categories · Manage Trips · Manage Booking (+ submenu) · Trip Planner Requests ·
Trip Inquiries · Payments Manager (+ submenu). Use Dashboard and Team Members as comparison.

## Step 1 — audit (read-only)
For each page, find the route (holidaylanmark `routes/web.php`, organizer group) and the Livewire
component / controller, then trace one full page render: mount, render, #[Computed], child
components, Blade components. List every call to another service with file:line:
- inside a per-row loop? → HTTP N+1, give the formula and define N
- cached? (key, TTL) or repeated on every Livewire click
- timeout / retry
Separate per-page costs from costs shared by every organizer page (auth user, SidebarComposer,
NavbarComposer, OrganizerContext, bell). Mention the shared ones once.

For every N+1, open the RECEIVING service and check for an existing list/batch endpoint that can
return the needed fields. If none exists, propose an opt-in addition (like `include=contact`) with
method, route, params, response fields, authorization, limit, and missing-record behaviour.

## Step 2 — plan
A table per page: cause, fix, repos touched, risk, expected calls before → after (formula, no
invented timings). Order by gain ÷ risk. Stop and wait for my approval.

## Step 3 — implement ONLY the approved items, one page at a time
Rules:
- Same output: rows, values, empty states, filters, sorting, pagination, permissions, workspace
  (organizer_id) scoping, contact-reveal rules (root §5.4), error messages.
- New API fields must be opt-in so other callers get the same payload.
- Caller keeps a fallback to the old per-row call when the new field is absent (deploy order free).
- Map results by stable id, dedupe ids, never by response order.
- No cross-request caching unless I approve it (state scope, TTL, invalidation).
- Never cache a value that can mean both "empty" and "failed".
- No migrations, `.env` or server changes. Never run Pint. Never push (I push manually).
- Verify each fix: `php -l`, existing tests (borrow vendor if needed), and a call-count check that
  shows per-row calls before → after with identical rendered output.

## Step 4 — document each fix
- In `http-calls.md`, add the page as a new point with **Status** and a **Where to test** table
  (sidebar, menu item / URL, buttons to click, what is faster, what must look the same).
- Write a review per fix named after the task, e.g.
  `docs/performance/organizer-<page>-<topic>-review.md`, in the format of
  `tourists-contact-lookup-pr554-review.md`.
- End with: which repos to deploy, files changed, and order.