fix(uploader): set the manifest fallback so SPA deep links resolve

[vilenarios]

Problem

An arweave/paths manifest serves only the paths it lists, so any single-page app deployed with this tool 404s every route that isn't a real file — the root loads, /settings doesn't.

uploadFolder built the manifest with index but never fallback:

const manifest = {
  manifest: 'arweave/paths',
  version: '0.2.0',
  ...(indexPath && { index: { path: indexPath } }),
  paths: manifestPaths,
}

The README has advertised "404 Fallback Detection: Automatically detects and sets 404.html as fallback", but the string fallback appeared nowhere outside that README — documented, never implemented. Found while deploying console.ar.io: every deep link 404'd in production.

Change

• 404.html becomes the manifest fallback when the build emits one
• --fallback-file <path> overrides it, so an SPA that only builds index.html can point at that instead of inventing a 404 file
• A named file missing from the folder throws rather than silently skipping — skipping ships exactly the broken manifest this prevents
• README now matches the code

Shape matters: fallback takes an { id } where index takes a { path }. The v0.2.0 spec differs, and a { path } here is silently ignored by gateways.

Verification

• 6 new unit tests (tests/unit/uploader-manifest-fallback.test.ts) covering: 404.html detected; id-not-path shape; no fallback when absent (unchanged behaviour); explicit override; SPA opt-in via index.html; missing file errors
• Full suite: 62 tests, 9 files, all passing
• tsc --noEmit clean, pnpm build clean
• Verified on the built CLI: --fallback-file appears in deploy --help and upload --help