Stop the Recovery and Reuse modelizers throwing without core data

[ZayanKhan-12]

Description

Refs #73.

@MarkusPiotrowski asked for more detail on fairings — which ones reflew, and how they were recovered. Most of that is already written. Recovery has a fairings recovery chart splitting attempts into successes and failures per year, and Reuse reports reflownFairingsCount. Both blocks are commented out in Root.tsx, alongside recovery, reuse, starlink, dragon and people, after the r/spacex API shutdown the site banner mentions.

This PR does not turn them back on, but it removes the reason they cannot be.

The bug

Both modelizers index straight into arrays that are empty with the data the site currently receives, and reading through the missing element throws. Since the page is rendered at build time, each of these fails the whole build, not one section.

The Launch Library transformer reports every launch with landing: null and fairings.recoveryAttempt: false, and supplies no cores at all, so all four are hit on every build:

where	what is empty	what threw
landingHistory.ts	no landing attempts	landingAttempts[0].launch
fairingsRecovery.ts	no recovery attempts	recoveryAttempts[0]
Reuse/modelizer.ts	no cores	mostLaunchedCore.serial
getQuickestReuseTurnaround	no core flown twice	returned undefined while declared Turnaround

Running the two modelizers against a launch shaped the way the transformer produces them:

Recovery  LL2-shaped  -> THROWS Cannot read properties of undefined (reading 'launch')
Reuse     LL2-shaped  -> THROWS Cannot read properties of undefined (reading 'serial')

The charts now use an empty year range, which the rest of their code already handles, and the two Reuse lookups fall back to a placeholder.

This is the same shape of fix as #128, which I opened for the Payloads block after #120; these are the remaining blocks with the same problem.

Verified the working path is unchanged

Degrading is only worth anything if the numbers are still right when data exists. Running both modelizers over launches with real fairing, landing and core data:

RECOVERY
  fairings chart labels    = [2019,2020,2021]
    Success  [1,1,1]
    Failure  [0,1,0]
  landedBoostersCount      = 3
REUSE
  reflownFairingsCount     = 2
  mostReflownCore          = B1049 | Mission a, Mission c, Mission d

Each of the four guards is load-bearing: reverting any one of them individually puts two of the four cases back to throwing.

What this does not fix, and what #73 really needs

Worth stating plainly, because the fairings stats will read as zero even once the blocks are enabled: Launch Library 2 carries no fairing data at all. I checked the API rather than assuming — a launch fetched with mode=detailed has rocket.launcher_stage covering the booster (reused, landing, previous_flight, turn_around_time_days) and nothing about fairings anywhere. The transformer hard-codes fairings: { reused: false, recoveryAttempt: false, recovered: false } for every launch as a result.

Also worth noting for the issue itself: the "scooped from the water or caught by the net" distinction was never modelled, even under the old API. FairingsLaunch is only { recoveryAttempt, recovered, reused } — there is no ship or catch-method field to render. That part is a new data requirement, not a disabled feature.

Separately: a units bug I found but did not fix

formatDuration takes seconds, but Reuse/modelizer.ts passes a millisecond difference of two dates, so the quickest turnaround renders as 365000 days for what should be 365 days. Dragon's commercialCrewFlights.ts has the mirror problem, passing hours.

I left both alone. Fixing them properly means deciding what unit formatDuration should take and auditing every caller, which is a wider change than this one and not something I can check visually with the blocks disabled. Happy to do it separately if you would like.

Checks

Per CLAUDE.md, master does not typecheck clean, so I compared rather than assumed:

	baseline on master	with this change
npx tsc --noEmit	12 errors	12 errors, identical set
npx eslint on changed files	clean	clean

I used npx eslint rather than yarn test:lint, which is eslint --fix and rewrites files. I did not run gatsby build: .nvmrc pins Node 16 and I had 18, and these blocks are disabled so a build would not execute this code. They are pure functions, which is why exercising them directly is a meaningful check.

CLAUDE.md is in my other open PR (#126) and is not duplicated here.