feat(dispatcher): catalog-driven MEOS-function dispatcher (step 4 foundation)

[estebanzimanyi]

Stacks on #4. Step 4 of docs/MEOS_API_INGESTION_PLAN.md — the catalog-driven dispatcher that the 5 'REPLACE' resource modules will delegate to in follow-up PRs.

What it ships

mobilityapi/dispatcher.py:

• Loads vendor/meos-api/meos-idl.json at construction; honours an explicit catalog_path= for tests.
• Filters to network.exposable functions only when enrichment fields are present; otherwise treats every function as exposable.
• FunctionSignature dataclass: name / category / params / return_type / decode_per_param / encode_return / description, all populated from the catalog (enriched or bare).
• dispatch(function_name, params) -> Any:
  • validates the parameter set against the catalog signature
  • resolves the MEOS function via an injected resolver callable
  • invokes it with validated keyword args
  • returns the result; the caller owns encoding to JSON / WKB

tests/test_dispatcher.py — 12 tests, all passing locally (python3 -m pytest tests/test_dispatcher.py -v):

• catalog load (default path, explicit path, FileNotFoundError)
• FunctionSignature.from_catalog_entry (basic fields, enriched wire metadata, fallback when wire absent, non-exposable filtering)
• dispatch contract (resolver invocation, unknown function, missing param, unexpected param, default stub resolver raises NotImplementedError)
• integration sanity (the 5 MovFeat dispatch candidates named in the ingestion plan are present in the vendored catalog)

Resolver pattern

Production wiring lands when the first endpoint migrates:

import pymeos
d = Dispatcher(resolver=lambda name: getattr(pymeos.functions, name))

For tests, a stub registry suffices:

d = Dispatcher(resolver=_stub_registry(tpoint_speed=fake_tpoint_speed))

What this PR does NOT change

• Existing hand-written endpoint modules in resource/* are unchanged. The plan's 5 REPLACE candidates migrate to the dispatcher one PR at a time:
  • resource/temporal_geom_seq/ (Create, Retrieve) → temporal_from_mfjson / temporal_as_mfjson
  • resource/temporal_geom_query/velocity.py → tpoint_speed
  • resource/temporal_geom_query/acceleration.py → temporal_derivative
  • resource/temporal_geom_query/distance.py → tpoint_cumulative_length
  • resource/temporal_properties/ → temporal_as_mfjson
• PyMEOS is not yet a dependency (the dispatcher is resolver-agnostic; the production resolver lands with the first endpoint migration).
• OGC API – Moving Features path mapping is in MEOS-API #13. Step 5 of the ingestion plan consumes that mapping; this PR is the dispatch core shared between step 4 and step 5.

Dependency chain

Stacks on / depends on	Status
MobilityAPI #4 (vendor MEOS-API artefacts)	OPEN, green
MobilityAPI #3 (ingestion plan)	OPEN, green
MEOS-API #13 (movfeat OpenAPI projection)	OPEN — needed for step 5, not for this PR

When #4 lands, this PR's diff narrows to just the new mobilityapi/ + tests/ files.