bee-check 0.5.0

Retrievability checker for Ethereum Swarm references. Multi-vantage stewardship probes, per-chunk drill-down, and one-shot re-seed.
Documentation
# "My upload looks lost"

## Symptom

You just uploaded content and got a reference back. The reference
works locally:

```bash
curl -I http://localhost:1633/bzz/<ref>/    # 200 OK
```

…but stewardship says it isn't retrievable:

```bash
bee-check <ref> --bee http://localhost:1633
# status  Unretrievable
```

## Diagnose

The most common cause is a **deferred upload that hasn't been pushed
to the network yet**. Bee's default is to accept the upload, return
the reference immediately, and push chunks in the background. The
`/bzz` endpoint serves from the local store; the `/stewardship`
endpoint deliberately goes through the network retrieval path —
which means it can't see chunks that haven't yet propagated.

Confirm with `--per-chunk` from a *different* vantage. If most or
all chunks miss everywhere except your uploading node, you're
looking at a not-yet-pushed upload.

## Fix

**Option A: wait.** Background push completes on its own. Re-run
`bee-check` after a few minutes.

**Option B: force an immediate push.** Re-upload synchronously by
sending `swarm-deferred-upload: false` on the original upload —
Bee will only acknowledge after every chunk is pushed and stamped.

**Option C: re-seed with a current batch.** If the original batch is
fine but you want chunks pushed now:

```bash
bee-check <ref> --reseed --stamp <current-batch-id> --bee http://localhost:1633
```

This re-fires the stamp and re-pushes anything the network is
missing.

> **Note:** If your local store has been garbage-collected and
> there's no peer with the chunks, **none of these work** — the
> upload is genuinely lost. That's why deferred-upload reliability
> matters: you only get one chance to push.