feat: add remotePatterns support for external storage providers

[edmogeor]

Closes #1.

What

Adds a remotePatterns config option so the plugin can optimize images served from external upload providers (S3, Google Cloud Storage, etc.), mirroring next/image remotePatterns. Local /uploads/ paths remain allowed by default — no breaking change.

'next-image': {
  config: {
    remotePatterns: [
      { protocol: 'https', hostname: 'storage.googleapis.com' },
    ],
  },
},

How

• Pattern matching (server/src/remote-pattern.ts) — faithful port of Next.js's matchRemotePattern/hasRemoteMatch, using the same picomatch engine so wildcard/edge-case behavior is identical.
• Controller (controllers/image-optimize.ts) — replaces the flat /uploads/ check with Next.js's validation flow: reject protocol-relative //, keep /uploads/ for local, and for absolute URLs require http(s) + a matching remotePattern.
• Service (services/image-optimize.ts) — fetches allow-listed remote images over HTTP (10s timeout, 50 MB cap) instead of only reading the local public/ dir.
• Client loader (strapi-next-image/src/image-loader.ts) — previously stripped every absolute URL to a relative path, which silently defeated remotePatterns. Now strips only same-origin Strapi URLs and forwards cross-origin ones absolute. Requires the loader path/base to be set to your Strapi URL when using a separate frontend.

Notes

• SSRF protection is preserved: absolute URLs are allow-list-only (400 "url" parameter is not allowed otherwise).
• The remote download size cap is enforced after buffering the response body — it rejects oversized images but does not stream-abort mid-download. Fine for trusted, allow-listed origins; worth revisiting if that assumption changes.

Versioning

Both packages bumped 1.0.1 → 1.1.0; CHANGELOG updated.

Testing

• New unit tests for matchRemotePattern/hasRemoteMatch, the config validator, controller allow-list branches, and loader cross-origin forwarding.
• Full suites pass: 102 (plugin) + 132 (client). Both typechecks clean.