A check-job failure sends no Slack notification, so a dead nightly is silent

## Summary

If the `check` job fails, no Slack notification is sent. The nightly can stop producing prebuilds
indefinitely and the only evidence is the Actions run list.

## Why

`on-release-failure` is gated on `needs.check.outputs.should_build == 'true'`:

```yaml
on-release-failure:
if: failure() && !cancelled() && needs.check.outputs.should_build == 'true'
```

But `should_build` is only written at the *end* of the `check` job:

```yaml
echo "should_build=$SHOULD_BUILD" >> $GITHUB_OUTPUT
```

Every `exit 1` in `check` fires before that line — the version.h parse failure, the
"release already exists" guard, and the releases-API status guard. So when `check` itself fails,
the output is empty, `'' == 'true'` is false, and the notifier job is skipped. The guard exists to
keep quiet on the no-op path (nightly finds no new release), but it cannot distinguish "nothing to
build" from "never got far enough to decide".

## Sequence

1. 02:30 nightly runs. `api.github.com` returns 503 through all retries.
2. The releases-API guard exits 1. `check` fails.
3. `on-release-failure` evaluates `needs.check.outputs.should_build == 'true'` → false → skipped.
4. No Slack card. Nobody learns the nightly stopped.
5. Repeats every night until someone happens to look at the Actions tab or notices rocksdb-js has
had no update PR for a while.

## Why it is filed separately

Pre-existing, and independent of the concurrency work in
[#19](https://github.com/HarperFast/rocksdb-prebuilds/pull/19) — surfaced by the cross-model review
of that PR. #19 adds `--retry` to that curl, which narrows the transient-5xx trigger but does not
close the notification gap, and #19 deliberately left `on-release-failure`'s condition alone.

## Suggested fix

Distinguish "decided not to build" from "failed before deciding". Either:

- Write `should_build=false` early and update it, so the output is always present, and gate on
`needs.check.outputs.should_build != 'false'`; or
- Add a `needs: [check]` notifier for check-job failure specifically, gated on
`needs.check.result == 'failure'` — which is populated regardless of how far the job got.

The second is more direct: `needs..result` is exactly the signal being approximated here, and
it does not depend on the job reaching its last line.

## Location

`.github/workflows/build.yml` — the `check` job's `exit 1` paths and `on-release-failure`'s `if:`.

Start in .github/workflows/build.yml by reading the check job's exit 1 paths and the on-release-failure if condition. Trace the needs.check outputs and needs.check.result behavior, then verify the workflow keeps the no-op path quiet while notifying when check fails before producing its output.

Written by the indexing model from the issue text.