Fix Lens share URLs stripped by SEO redirects

[mneveroff]

Summary

Hotfix for shared Lens viewpoint URLs broken by the SEO redirect logic in #34.

After #34 deployed, links like /lens/?c=55.36…&m=tl&d=nao… loaded the default map position instead of the shared view. The redirect middleware was stripping all query parameters to canonicalise tracking URLs (?ref=neveroff.dev), but Lens uses the same query string for app state (c, m, d, t, b, y, cy).

This PR narrows redirects to tracking params only and preserves Lens state when adding the trailing slash.

Changes

lens/src/server.mjs

• Only 301-strip query strings that contain exclusively tracking params (ref, utm_*)
• /lens?c=… → /lens/?c=… (preserve viewpoint params)
• /lens/?ref=… → /lens/ (strip tracking only)
• /lens/ with Lens state params → 200, no redirect

lens/src/index.ts

• Parse dataset from d as well as l (share links generated by map.ts use d, but startup only read l)

Context

Follow-up to #33 (SEO migration) and #34 (redirect loop fix). Canonical tag on /lens/ still handles SEO consolidation for any stray tracking URLs Google has already seen.

Test plan

• curl -s -o /dev/null -w "%{http_code}" 'http://localhost:3939/lens/?c=55.364712,-3.529857,8.32,25&m=tl&d=nao&t=o&b=l&y=2022&cy=2022' → 200
• curl -sI 'http://localhost:3939/lens/?ref=neveroff.dev' → 301 → /lens/
• curl -sI 'http://localhost:3939/lens?c=55.36…' → 301 → /lens/?c=55.36… (params preserved)
• Browser: shared viewpoint URL restores map position locally
• After deploy: https://weeforest.org/lens/?c=55.364712,-3.529857,8.32,25&m=tl&d=nao&t=o&b=l&y=2022&cy=2022 loads correct view
• After deploy: https://weeforest.org/lens/?ref=neveroff.dev still redirects to /lens/