Stop discarding the render failure's cause, and refuse startingLakePositions (#227)

[wormeyman]

Second of three PRs finishing #227's phase 7. PR 1 was #362; the deletion itself
follows this one.

Closes #341.

A render failure produced no usable message anywhere

The cause was discarded three separate times:

step	file	what it did
producer	elevationRender.worker.ts	serve() had no try, so it threw instead of posting RenderErrorMessage
transport	useElevationPreview.ts	onerror was declared with no argument and substituted a constant
consumer	ElevationPreviewPanel.vue	a bare catch substituted "Preview failed."

#341 covers only the consumer. Fixing any one alone still leaves a useless
message, so the three go together.

The producer is worse than a lost string. A throw out of onmessage fires the
worker's error event, and the host reads that as a crashed worker: it
terminates the slot and rejects every tile the slot was holding. One bad request

• a spawn list over the ABI cap, a view the module refuses - therefore failed
  every good render in flight beside it, and reported six words that named none of
  them. serve() now catches, settles exactly the request that failed, and leaves
  its siblings running.

"Preview failed." is also the string PreviewPanel.vue produces from the
unrelated Docker preview service, which #341 records having been confused by.

The startingLakePositions refusal

Now the first statement of runRenderRequest, before the planet split. The
two checks it replaces sat inside leaves of the view/planet dispatch and missed
three cases between them:

• Vulcanus - that branch returns before the Nauvis gate is ever evaluated.
• Fulgora - likewise, and this one is live: findIslands posts
  planet: "fulgora", view: "landmask".
• view: "landmask" on Nauvis - in the outer view test, absent from the
  Nauvis gate's allowlist.

It refuses rather than ignores because the type outlives every consumer:
eval/ctx.ts and expressions/elevationIsland.ts survive #227 while every
module that acted on the override does not. Accepting and ignoring it would
render a different map than the caller asked for and say nothing.

The NAUVIS_MAX_STARTING_POINTS clause deliberately stays. Its fallback is the
TypeScript path, so it goes with the deletion rather than here - and removing it
then is only safe because serve() is wrapped now.

Planted, not predicted

plant	result
serve() throws again instead of posting	RED - both worker error tests
onerror substitutes the constant again	RED - carries the crash's own message
the panel discards the cause again	RED - shows the render's OWN message
the guard moves into the elevation dispatch leaf	RED - refuses on every planet and view
the guard gains a length > 0 test	RED - refuses an EMPTY list too

The fourth is why there is a block sweeping Vulcanus, Fulgora and Nauvis
landmask: every other assertion in that describe is Nauvis lakes, so a guard
put back into a leaf would satisfy all of them and still let the three real holes
through.

One plant corrected a note rather than the code

The guard was written !== undefined on the stated grounds that a truthiness
test would let [] through. Planting truthiness came back GREEN: [] is
truthy in JavaScript, so both forms refuse it and the two agree on every value
the field can legally hold. The form that does let [] through is a length
test, which is the plausible mistake because it reads like a tidy-up. That is
what the empty-list block now guards against, and the comment says so.
!== undefined stays, because it states the type's own distinction rather than
relying on the coincidence.

Two tests strengthened rather than added

The panel's error test asserted only that an error element existed, which
stayed true the whole time the cause was being thrown away - so #341 was
invisible to it. wasmElevationRenderParity.spec.ts's carve-out block asserted
the opposite of what is now true and became the refusal's own coverage.

Gate

pnpm run verify green in 12m42s, VERIFY_RC=0 read out of the log rather than
off the pipe. 1606 tests, up 7.