feat: accept UN/LOCODE port codes as origin/destination

[mayurrawte]

Summary

Logistics and supply-chain users think in port codes, not coordinates. This PR lets a UN/LOCODE string be used anywhere an origin/destination is accepted:

import 'searoute-ts/ports'; // enables UN/LOCODE strings on the core API
import { seaRoute } from 'searoute-ts';

seaRoute('CNSHA', 'NLRTM');     // Shanghai → Rotterdam
seaRoute('CNSHA', [4.4, 51.9]); // mixing a code and coordinates is fine

Design

• Dataset behind a subpath export. The ~1,600-port dataset ships as searoute-ts/ports so the core stays lean and consumers only pay for it if they use it. Importing the subpath (for any export, or purely for its side effect) registers a UN/LOCODE→coordinates resolver into the core, which is what enables seaRoute('CNSHA', …). package.json sideEffects is narrowed to an array so bundlers keep that registration.
• Resolve then reuse the pipeline. A string input is resolved to [lon, lat] and then follows the existing snap → Dijkstra path — no new routing logic. Works for seaRoute, seaRouteMulti, and seaRouteAlternatives.
• Clear errors. Unknown/malformed codes throw the new UnknownPortError; if a code is passed without the dataset registered, the error explains to import searoute-ts/ports.

New API

• searoute-ts/ports: lookupPort(code) → { code, name, country, coordinates }, resolvePort(code) → [lon, lat], PORTS, PORT_COUNT, types Port / PortRecord.
• Core: UnknownPortError, registerPortResolver, type PortResolver; PointInput now also accepts string.

Dataset & provenance

• Source: marchah/sea-ports (MIT), itself derived from UN/LOCODE. Regenerate with scripts/build-ports.cjs (documented URL + steps in the script header).
• 1,610 codes (primary UN/LOCODEs + aliases), indexed case-insensitively. Entries without valid coordinates are dropped. Coordinates are port-city granularity — fine here since inputs are snapped to the network anyway.
• I deliberately used this seaport-specific dataset rather than the raw UN/LOCODE CSV: the CSV has empty coordinates for many major seaports (Shanghai, Jebel Ali, Felixstowe, Valencia, Port Said…), so it can't power the headline example.

Notes

• The dataset is embedded as a parsed JSON string in src/ports/data.ts and compiled into both builds, mirroring the existing marnet.ts convention (it does ship in both CJS and ESM; the shared-asset approach from Halve package size: load the network from a single shared asset instead of inlining it in both builds #10 could later apply here too, but that's out of scope).

Validation

All steps CI runs, from a clean tree:

• npm ci
• npm run lint ✅
• npm run format:check ✅
• npm run build ✅
• npm test ✅ (54 tests; +1 core test that a code throws UnknownPortError without the dataset, +9 in a new src/ports/index.spec.ts covering lookup/resolve, case-insensitivity, aliases, unknown-code errors, and seaRoute('CNSHA','NLRTM') landing in the Shanghai→Rotterdam distance band)

Also verified end-to-end against the built dist in both CJS (require) and ESM (import): seaRoute('CNSHA','NLRTM') ≈ 19,753 km, mixed code+coord identical, PORT_COUNT 1610, unknown code → UnknownPortError.

Closes #7