Remove HTTP N+1==Batch Per-Row API Requests and Remove Repeated or Unused Calls for Faster Lists and Dashboards

READ: https://www.debug.school/rakeshdevcotocus_468/laravel-microservices-performance-optimization-a-priority-wise-plan-to-speed-up-holidaylandmark-2o9l

Per-row API calls ko batch karo; unused calls hatao

=========Expected impact:======================
Lists aur dashboards par major improvement, especially zyada records hone par.
Replace Per-Row API Calls with Batch Requests
Reduce Repeated and Unused API Calls
Fetch Data Together for Faster Lists and Dashboards
Load Multiple Records in Fewer API Requests
Speed Up Pages by Removing Extra API Calls
=======================prompt======================================

Act as a senior Laravel and microservices performance engineer. Audit only HTTP N+1 calls in HolidayLandmark to identify repeated upstream requests and unnecessary API lookups.

Enter Plan Mode first. Do not change code or configuration until I review and explicitly approve your proposed approach.

Read the project’s AGENTS.md and CLAUDE.md. Verify the installed Laravel version and existing API contracts before recommending changes.

Inspect these four areas separately:

1. Tourists per-row contact lookup:
   - Trace tourist list rendering and contact retrieval.
   - Identify HTTP requests executed inside loops, row components, accessors, or Blade views.
   - Evaluate fetching contacts in one authorized batch and mapping results by immutable user ID.
   - Preserve contact visibility, missing-contact handling, filters, sorting, and pagination.

2. Organizers expanded metrics:
   - Trace metric requests when organizer rows or panels expand.
   - Identify repeated requests for the same organizer and separate calls that could be aggregated.
   - Evaluate on-demand loading, request-scoped reuse, or a batch/aggregate endpoint.
   - Preserve metric accuracy, refresh behavior, and permission checks. Avoid preloading expensive metrics that users never open.

3. Team member user pool:
   - Inspect how team members and candidate users are fetched and matched.
   - Identify repeated user lookups or fetching the entire user pool to resolve a small set of members.
   - Propose retrieving only required users through bounded, authorized batch requests.
   - Preserve tenant isolation, roles, search, invitation eligibility, and pagination.

4. Bookings unused getByPublicRef:
   - Find all relevant getByPublicRef calls and trace how their results are used.
   - Confirm whether each call supplies data, checks existence or ownership, triggers side effects, or affects error handling.
   - Propose removing a call only when its result and behavior are genuinely unnecessary.
   - Preserve booking authorization, public-reference validation, and existing failure responses.

For each area, inspect both the calling service and receiving API. Prefer existing batch endpoints. If a new endpoint is needed, show the proposed API contract, authorization, input limits, response mapping, and missing-record behavior. Do not simply move N+1 work into database queries inside the receiving service.

For every finding, show:

- Affected page and user action.
- Exact file paths and current line numbers.
- Existing code snippet.
- Current HTTP call sequence and count, expressed using N where appropriate.
- Why the calls are repeated or unnecessary.
- Whether the issue is confirmed or needs measurement.
- Recommended approach and exact locations to change.
- Clearly labelled proposed before/after code—do not apply it.
- Expected HTTP call count after the fix.
- Risks and focused validation steps.
- How to compare upstream requests, receiving-service database queries, response payload size, and response time before and after.

Preserve filtering, sorting, pagination, totals, permissions, tenant isolation, and existing API error behavior. Handle empty lists, duplicate IDs, missing records, partial failures, and batch-size limits. Use concurrency only where batching is unavailable; explain that parallel requests reduce waiting time but do not eliminate N+1 calls.

Finish with a prioritized implementation plan based on measured call count, latency, frequency of use, and implementation risk. Explain the proposed fixes clearly enough for me to review and recommend adjustments.

Stop and wait for my approval. After approval, implement only the agreed changes, preserve existing functionality, and report changed files, line numbers, validation results, and measured improvements. Avoid unrelated refactoring.