Cryptify staging: enable CORS for browser callers (localhost + addin.postguard.eu)

[rubenhensen]

Summary

`https://fileshare.staging.postguard.eu/fileupload/init\` (and the rest of `/fileupload/`, `/filedownload/`) does not return CORS headers. Browser consumers calling from a different origin hit:

```
Access to fetch at 'https://fileshare.staging.postguard.eu/fileupload/init' from origin 'https://localhost:3000' has been blocked by CORS policy:
Response to preflight request doesn't pass access control check:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
```

Affected callers

• Office Add-in dev (`https://localhost:3000\`) — pg-js's `sealed.upload()` and `createEnvelope` large-payload branch fail.
• Production Office Add-in once deployed (`https://addin.postguard.eu\`).
• Anything else cross-origin that uses pg-js in a browser tab.

(The PostGuard website itself is presumably same-origin-ish or proxies through a Next/Svelte server route, so it doesn't see this.)

Suggested fix

Add CORS to the Cryptify endpoints, allowing at minimum:

• `https://localhost:3000\` (dev)
• `https://addin.postguard.eu\` (Outlook prod)
• Any other origins where pg-js is expected to run

The same fix is needed on production Cryptify (`fileshare.postguard.eu` if separate).

`Access-Control-Allow-Origin` plus `Access-Control-Allow-Headers: Content-Type, Authorization, ...` and the matching preflight `Access-Control-Allow-Methods: POST, GET, PUT, DELETE`.

Downstream

Even with CORS fixed, pg-js leaks an unhandled rejection when this path fails — tracked separately at encryption4all/postguard-js#32.

Repro

```bash
curl -i -X OPTIONS -H 'Origin: https://localhost:3000' -H 'Access-Control-Request-Method: POST' https://fileshare.staging.postguard.eu/fileupload/init
```

→ no `Access-Control-Allow-Origin` in the response.

[dobby-coder]

/dobby fix — Enable CORS on the Cryptify file server so browser callers from https://localhost:3000 (Office Add-in dev) and https://addin.postguard.eu (Outlook prod) can reach /fileupload/* and /filedownload/*. The fix lives in encryption4all/cryptify (the Rust/Rocket service behind fileshare.postguard.eu), not in this repo — trace it there. cryptify already configures CORS via rocket_cors + config.toml; add the listed allowed origins plus matching Access-Control-Allow-Headers (Content-Type, Authorization) and Access-Control-Allow-Methods (GET, POST, PUT, DELETE), and make sure the OPTIONS preflight succeeds (verify with the curl -i -X OPTIONS repro in this issue). Build and run cryptifys test suite, then open a draft PR against cryptify referencing this issue.

[dobby-coder]

On it! I'm picking up the CORS configuration fix for the cryptify repo and will open a draft PR with the change.

[dobby-coder]

Reviewed and gated cryptify#179 — the CORS fix looks solid. The allowed origins regex is properly anchored (no spoofing risk), DELETE is now advertised in preflight, and both happy-path and rejection-path tests are green.

Caught two small things and fixed them inline: a misleading comment about config validation (the tests use a hand-maintained copy, not conf/config.toml), and swapped Refs for Closes encryption4all/postguard#154 in the PR body so this issue auto-closes on merge. PR is now out of draft and rubenhensen has been requested for review.