Add implementation plan for composite-key Occurrence detail page

[karilint]

Motivation

• Provide a clear, implementation-ready plan to add a dedicated Occurrence detail page backed by now_ls while keeping the database schema unchanged.
• Capture routing, backend API shape, frontend types/hooks, UI tab structure (including an Updates placeholder tab), and composite-key identity requirements (lid + species_id) so implementation stays DRY and safe.
• Surface risks, acceptance criteria, and a granular task breakdown across frontend, backend, and fullstack work to guide development and review.

Description

• Add a planning document at docs/occurrence-detail-page-plan.md that contains assumptions/scope, a high-level cross-layer plan, a machine-readable JSON task list (T1–T6), risks & mitigations, out-of-scope items, and a definition-of-done checklist.
• Require composite-key routing design (e.g. /occurrence/:lid/:speciesId) and explicit guidance to avoid any DB/Prisma migrations or table renames.
• Specify the required backend read endpoint shape, frontend types and query hook, an OccurrenceDetails UI using existing DetailView patterns, and changes to list-to-detail navigation preserving query state.
• Include testing expectations and rollout safeguards (lint/TS checks, unit/integration tests, and targeted frontend tests) and estimates/priorities for each task.

Testing

• Ran linting across the repo via npm run lint and the frontend/backend linters; the lint step completed successfully.
• Ran TypeScript checks via npm run tsc (both backend and frontend) and they completed successfully.
• The plan includes explicit test plans for each task (router tests, backend integration tests for composite-key lookup, frontend component and navigation tests) to be implemented during feature development.

---

Codex Task