feat(storage): add URL upload/download support for local storage provider

[ChrisPdgn]

Summary

• Add an embedded HTTP file server to the local storage provider so getUploadUrl, getSignedUrl, and getPublicUrl work the same way as cloud providers (presigned-URL pattern on port 3100 by default).
• Implement provider lifecycle cleanup via dispose() so the HTTP server is torn down and recreated on config changes (activate, deactivate, provider switch).
• Fix local provider directory creation: store() now creates parent dirs before writing, and createFolder() uses synchronous recursive mkdirSync instead of racy async mkdir callbacks.

Test plan

• POST /storage/upload with a new folder path succeeds without manually creating directories
• PUT to the returned upload URL writes file bytes to disk
• GET on the local storage URL serves the file with correct MIME type (text + image)
• GET /storage/getFileUrl/:id returns the local storage URL for private files
• Verify HTTP server restarts cleanly when storage config changes (port/path/provider switch)
• Verify module deactivation calls dispose() and releases port 3100

[kkopanidis]

We need to support some sort of authentication mechanism in the non-public URLs of the provider. For example the "upload" URL part needs something too. We can somehow probably "re-use" authentication's JWT

[ChrisPdgn]

Good point on needing auth on the non-public local storage URLs (especially upload). We looked at reusing the authentication module's JWT, but went with HMAC-SHA256 signed URLs instead — the same pattern S3/Azure/GCS use for presigned URLs.

What we implemented:

• getUploadUrl() and getSignedUrl() now return URLs with sig and expires query params
• The embedded HTTP server (port 3100) validates the signature and expiry before serving
• PUT without a valid signature → 403 (upload URLs are protected)
• GET with a valid signed URL → serves the file (private download URLs are protected)
• getPublicUrl() stays unsigned — public files are meant to be openly accessible, and the URL is stored permanently in the DB

Why HMAC instead of auth JWT:

1. Matches production semantics — cloud providers don't use user JWTs for presigned URLs; they use HMAC signatures scoped to a specific path + HTTP method + expiry. Local dev should behave the same way.
2. No cross-module dependency — the storage provider doesn't need access to authentication's jwtSecret or grpcSdk. It's self-contained.
3. Operation-scoped — a GET signature can't be used for PUT and vice versa. JWTs don't carry that constraint.
4. Time-limited by design — uses the same 1-hour SIGNED_URL_EXPIRY constant as AWS/Azure/Aliyun. JWTs have their own longer-lived expiry tied to user sessions.
5. No JWT in URLs — putting bearer tokens in query params would leak them in server logs, browser history, and referrer headers. HMAC signatures are opaque and purpose-built for URL-based auth.

The signing secret is ephemeral per provider instance (generated on startup). If the server restarts, outstanding signed URLs expire — same as when cloud signing keys rotate. Upload and download URLs are always generated on-demand through Conduit's authenticated endpoints, so this is fine in practice.