Single-read multi-product tile jobs (F3 core) - #75

- create_lpc_pipeline now returns tile jobs from create_tile_pipelines
  (issue #14 direction: one reader-agnostic core builder for EPT and
  local input), replacing its four per-product pipeline copies
- In-pipeline reprojection injected once via extra_pipeline_kwargs and
  shared by every product chain, so dsm+intensity and the DTM pair merge
  into chained-writer executions: 2 local reads per tile instead of 4
- save_pointcloud preserved as a chained writers.las before the DSM
  writer (legacy behavior verbatim, including the historical .laz.laz
  double-extension filename); only emitted when dsm is requested
- No cache step for local input (files are cheap to re-read)
- Commit-1 legacy adapter removed; rasterize has one executor code path
- New offline test: LPC job structure, reprojection stage, .laz.laz
  save writer, end-to-end execution, dsm-less subset

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The product raster CRS depended entirely on the LAS-header SRS surviving
the cache write/read round-trip. On another environment's PDAL/GDAL build
the SRS did not reconstruct on read, so writers.gdal wrote CRS-less
rasters and every tile failed check_raster_validity (SF rerun aborted,
100% of tiles invalid); this env reconstructs it fine, which is why the
UW-campus A/B and local SF repros passed.

Make it deterministic: thread the EPT's declared SRS (POINTCLOUD_CRS[i],
from ept.json) into create_tile_pipelines and stamp it on both ends of the
cache round-trip -- a_srs on the cache writers.las and override_srs on the
cache readers.las -- so tiles carry the CRS regardless of LAS-header
round-trip behavior. Non-cached (single-product, reader inlined) and LPC
(in-pipeline reprojection) paths are unaffected. _pdal_srs_string renders
an EPSG code when available, else WKT.

Tests: assert the stamps appear in the generated pipelines; reproduce the
failure with a deliberately untagged cache LAZ (CRS-less invalid raster)
and prove override_srs recovers the CRS. Verified live on a tiny SF AOI
via rasterize-projects: 3/3 all products valid, tiles EPSG:3857, mosaic
UTM 10N G2139.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Empty tiles (a survey does not cover part of the shared AOI) previously
each wrote a full-size CRS-less nodata raster, logged a spurious
"invalid raster" ERROR, and counted as a failed tile -- flooding the log
and making the final tally unreadable (e.g. "190/340" with 150 merely
empty). And a project with zero coverage over the AOI crashed with
"list index out of range" at the single-tile rename, while an empty
mosaic list failed cryptically ("vrt: No such file or directory").

- execute_tile_job now returns {"empty": bool, "outputs": {...}}. The fetch
  point count (via pipeline.execute()) detects a 0-point tile: skip the
  product executions, write nothing, log no ERROR, report empty.
- rasterize tracks empties separately from failures: "N/M tiles had no
  points (survey does not cover them)" instead of counting them failed;
  "failed" is now measured against data-bearing tiles only.
- No-data guard: if no product has any valid tile (0 readers or all-empty),
  skip mosaic/reprojection/stamping and finish with run_status completed +
  a "no data" note (driver marks the project completed, not failed) instead
  of an IndexError.
- raster_mosaic raises a clear ValueError on an empty input list instead of
  the cryptic downstream VRT error.

Verified on a mixed land/water SF AOI via rasterize-projects: covered
project completes with valid mosaics; a non-covering project finishes
cleanly as no-data. Tests: F5-lite empty-tile (empty=True, no rasters,
no ERROR); existing execute_tile_job tests updated to the new return shape.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>