Performance: trim Overpass query, add CPU-usage control, and opt-in pipelined tile merge

[TonyD365]

Summary

Three independent improvements aimed at generating large areas faster, plus a small
follow-up fix. Only the Overpass query change affects default output; the new generation
feature is opt-in and defaults off.

1. Overpass: drop the unfiltered way; selector

The query included a bare way; that pulled every way in the bbox (and all their
nodes), regardless of tags. The renderer only dispatches ways with recognised tags
(building / highway / landuse / …), which already have explicit selectors, and multipolygon
member ways are still fetched via way(r.relsinbbox). The bare selector only added data
that gets discarded — a major source of oversized responses, timeouts, and the resulting
multi-server retry cascade on large areas.

• Follow-up: added an explicit nwr["area:aeroway"] selector, because the renderer handles
  area:aeroway (airport aprons / taxiway polygons), which previously rode in only via the
  bare way;.

2. CPU-usage control

Generation now runs in a dedicated rayon pool sized to a new setting (cpu_percent,
default 90%, range 10–100). A scoped pool is used because rayon's global pool can only
be built once per process, so this is the only way the setting can take effect per-run
without a restart. Exposed as a GUI "CPU Usage" slider and a --cpu-percent flag;
RAYON_NUM_THREADS still overrides. Lets users push past the previously hard-coded 90% cap.

3. Opt-in pipelined tile merge

Phase 2 (merging each tile into the shared editor) is sequential, so worker cores sit idle
during merges. Behind an opt-in toggle, batch N's merge now overlaps batch N+1's placement
via rayon::join. Merge order is unchanged (in-order, batch by batch), so output is
bit-exact vs. the default path. Enabled via a GUI "Faster merge" toggle, a --pipeline-merge
flag, or the ARNIS_PIPELINE_MERGE env var; default off.

Testing

• CI green: cargo build --all-targets --all-features --release, clippy (-D warnings),
  and unit tests all pass.
• On a large metropolitan-area generation at 1:1 scale (~80×60 km, ~9,900 tiles), enabling
  the pipeline lowered the in-app ETA from ~9h39m to ~6h58m at the same progress point
  (~28% faster). This is an observation, not a controlled benchmark — output equivalence
  can be verified with ARNIS_BLOCK_HASH=1 (the per-region content hash should match
  between the default and pipelined runs).

Notes

• The three changes are logically independent; happy to split into separate PRs if preferred.

[TonyD365]

@louis-e
Note: the failing "benchmark" check is the known fork-PR limitation —
the benchmark runs fine, but posting its result as a PR comment needs a
write-scoped token, which fork PRs don't get ("Resource not accessible by
integration"). Nothing actionable on my end; the CI Build checks pass.
Please merge the PR.

[TonyD365]

@louis-e

[TonyD365]

@louis-e