fix(pipeline): surface reactive fallback failures and retry them next run

[ddeboer]

Fix #804

When the reactive dump fallback imported the dump but then failed before or during the re-run, two things went wrong at once. The error never reached the log, because ConsoleReporter.stageFailed only printed while a spinner was active, and the fallback catch block fires just after the import spinner has finished. And the dataset was recorded failed under the dump’s fingerprint, so a following run in which the endpoint failed probing skipped it as unchanged until the dump itself changed.

Changes

• @lde/pipeline-console-reporter: stageFailed now prints an error line when no spinner is running, the way importFailed already did. This covers the 'write', 'provenance' and 'reactive-dump-fallback' failures the pipeline reports outside any stage.
• @lde/pipeline: the dump’s change fingerprint is adopted only after the fallback re-run has succeeded. If runWriter.reset or the re-run throws, or a stage fails against the dump, the record keeps the endpoint’s fingerprint (null), so the dataset is retried on the next run instead of frozen out.
• Docs: the sparqlWithImportFallback entry in the pipeline reference now states this fingerprint behaviour, including that the stored dump fingerprint only skips a run in which the endpoint fails probing; when the endpoint passes probing, it is tried again first.

Not included

• The intermittent reset failure in @lde/search-typesense’s in-place dropWrittenThisRun (point 3 of the issue). With the reporter change it will show up in the log on the next occurrence, which is what is needed to diagnose it.
• The same freeze exists on the primary path: a dump-sourced dataset whose runWriter.flush throws transiently is recorded failed under the dump’s fingerprint. That is pre-existing and deserves its own issue, since the general fix (record infrastructure failures under a null fingerprint, or have shouldReprocess consult status) changes the skip-unchanged contract.