Perf/arc floodfill cache - #963

`FloodFillCache::get_or_compute` previously deep-cloned the cached
`Vec<(i32, i32)>` on every call. For dense forests or farmland polygons
these vecs can hold 10k-100k+ coordinates, so each handler invocation
copied tens to hundreds of kilobytes. The comment on the old clone even
acknowledged the tradeoff ("the cost is acceptable vs Arc complexity").

Wrapping the cached vecs in `Arc<Vec<_>>` replaces the copy with a
refcount bump and removes the transient duplicate allocation. For
Node/Relation fallbacks the empty result is served from a process-wide
`OnceLock` sentinel so the cold path doesn't regress either.

Call sites were updated mechanically:
- Move iterators (`for x in vec`) -> borrowing iterators (`for x in vec.iter()`)
- `for x in &vec` -> `for x in vec.iter()` (Arc derefs through method calls
  but not through `&` IntoIterator)
- buildings.rs still materializes an owned Vec because the hole-carving
  path needs `retain`; the deep copy there is cheap (building footprints
  are small) and keeps the rest of the function untouched.

Wall-clock impact on tested bboxes (Berlin/Potsdam/Grunewald) is within
measurement noise (<0.5%) — the dominant generation cost is block
placement, not cache fetch — but allocation pressure and peak memory
drop, which matters more as area size and polygon count grow. Tests
(65/65), clippy -D warnings, and fmt are clean.

The `--benchmark` flag now prints `generation_time_ms=` instead of
`generation_time=`; the workflow's grep was still looking for the old
key and would silently drop `gen_time` on every PR run. Parse the ms
value, round to the nearest whole second, and feed that into the rest
of the seconds-scale comparison logic so the verdict and PR comment
keep working unchanged.