Fail check, restore and backup jobs when they encounter errors

[poolpOrg]

A check over a corrupt store, a restore where some entries failed to export, and a backup that couldn't read some files were all being reported as successful. The job's status comes from the error each operation hands back to Main — a nil error becomes ReplySuccess — and none of these three surfaced their failures that way:

• check counted snapshot.Check() failures into the report's error tally but always returned nil, so a store with missing or corrupt packfiles still came back green. It now returns an error when any snapshot fails its check.
• restore and backup both commit/return nil even when some entries couldn't be written or read: restore's per-entry failures live only in events (snapshot.Export never returns them), and backup's live in the report's error count that nothing downstream inspected. A new terminalError helper — run after listener.Wait() has drained the event bus, the race-free point — turns either into a job failure.

This intentionally drops backup's previous success-with-warnings behaviour: a partial backup now fails like a partial restore or a failed check, rather than committing the snapshot and only emitting a warning. All three operations now share one rule — a partial run is not a clean success.

terminalError is a small pure helper so the verdict is unit-tested directly (terminal_error_test.go, replacing the old backup_warning_test.go).

This mirrors the check/restore fix in plakman/cmd/plaklet (PlakarKorp/plakman#1076); this repo's cmd/plaklet is a parallel implementation with the same gaps. The plakman check path was validated end-to-end against a MinIO store: backup → check (passes) → remove packfiles → check reports failed with check failed: 2 of 2 snapshot(s) had errors.

Verified: go build ./..., go vet ./..., go test ./... (32 tests pass).