fix: no retry when remote table metadata not found

[leno23]

Summary

• detect permanent remote metadata-missing errors before the download metadata retry loop keeps backing off
• warn and skip the affected table when its JSON metadata file is absent on remote storage
• preserve the existing optional .sql handling for incremental/embedded metadata and return non-not-found errors directly
• add a focused regression test for the not-found classifier patterns seen from common object stores

Tests

• go test ./pkg/backup -run TestIsRemoteMetadataNotFound -count=1
• go test ./pkg/backup -count=1

Closes #1379

[Slach]

Changed the missing-table.json behavior on download from silent skip to fail fast with an error.

Rationale: a missing table .json on remote is a permanent broken-backup condition. Silently skipping it restores fewer tables than the backup metadata claims, with no signal to the operator — a quiet data-loss footgun on restore. A 404 should surface, not be swallowed.

Kept the no-retry fix (the whole point of #1379): the not-found 404 still breaks out of the retry loop immediately instead of burning the ~35s exponential backoff. Detection now covers all backends' phrasings (S3 NoSuchKey, GCS doesn't exist/404, Azure BlobNotFound, FTP No such file or directory, SFTP file does not exist) — without this, FTP/SFTP/Azure were not classified and still retried.

Added per-backend integration tests (testMetadataNotFound_test.go, S3/SFTP/FTP/GCS/GCS-emulator/AZBLOB/COS) asserting download fails fast with a not-found error and no retry. All 7 green.

Note: the optional .sql (incremental/embedded) metadata is still skipped when absent, unchanged.