feat(obs/map): observation filtering + public web map

Summary

Enable filtering of observations by category, date range, location, and custom field values, then expose a public-facing web map that renders only observations explicitly approved for public display.

Motivation

Comapeo projects collect sensitive field data (land-use, conflict zones, ecological surveys) alongside observations intended for community-wide or public consumption. Currently there is no mechanism to:

1. Filter observations by structured criteria before sharing.
2. Publish a subset of observations as a read-only web map accessible without a Comapeo account.

Without these capabilities, every data-sharing workflow requires manual export and re-upload to an external tool, breaking the sync chain and creating privacy risk (sensitive observations can leak into public channels).

Proposed Filtering Mechanism

• Filter dimensions:
  • Category / .comapeocat schema
  • Date range (createdAt / observedAt)
  • Geographic bounds (within a lat/lng bbox)
  • Custom field values (e.g. tags.environmental_public = true)
• Filter expressions stored as serializable query objects (JSON) so they can be:
  • Saved and reused per project.
  • Applied on the server when serving the public map.
  • Validated against the project's category schema.
• Realtime reactive updates: when new observations sync to the server, the filter evaluation runs and the public map updates without manual rebuild.

Public Web Map

• Static or SSR page (e.g. /public/:projectId) requiring no authentication.
• Renders observations as a tiled or GeoJSON layer (MapLibre / existing GeoLibre integration — see #222, #223).
• Each observation popup shows only whitelisted fields (configurable per category) — never raw media or sensitive metadata.
• Served via CDN edge function with low-latency tile endpoint.

Privacy & Access Control

• Observations are opt-in to public display: a new field vis: "public" (or equivalent enum: private | project | public) on the observation record.
• Only observations with vis: "public" AND passing the project's public filter are rendered.
• Filtered/sensitive observations are never serialized to the public tile endpoint — server-side enforcement, not client-side filtering.
• Admin UI to audit which observations are currently public.

Technical Scope (initial estimate)

• Data model: add visibility enum to observation schema; migration for existing records (default private).
• Server API: filtered observation query endpoint + public tile/GeoJSON endpoint.
• Admin UI: filter builder + public-visibility toggle per observation.
• Public page: standalone static page or SSR route, MapLibre-based.
• Tests: filter engine unit tests, visibility enforcement integration tests, public page render test.

Open Questions

1. Should public visibility be set per-observation or inherit from category defaults?
2. Should the public map support custom category-driven popups or a fixed field whitelist?
3. Do we need rate-limiting on the public tile endpoint (see #136)?
4. Should public map URLs be unguessable (token in path) or fully open?

Acceptance Criteria

• User can define and save a filter expression against a project's observations.
• User can mark observations as "public" via the admin UI or mobile sync.
• A public-facing web map renders only public + filter-passing observations.
• Observations with vis != "public" are never present in the public tile/GeoJSON response (verified by integration test).
• Popups on the public map expose only whitelisted fields.
• Performance: public tile endpoint p95 < 200ms under realistic observation counts (benchmarked in CI).

No files, tests, or entry points are named. Start by resolving the open questions and reviewing the existing GeoLibre integrations in #222 and #223, plus rate-limiting context in #136. Done requires filtering, visibility enforcement, admin controls, a public map with whitelisted fields, integration and render tests, and the stated performance benchmark.