fix(meteor-backend): PulseVault upload reliability fixes

[Dharp02]

• Upgrade @mieweb/pulsevault 0.1.0 -> 0.1.1 (fixes missing dist/core.js crash on boot in this workspace's installed artifact state)
• Normalize x-forwarded-proto header (comma-separated/odd-cased values from upstream proxy chain caused 400 'Invalid x-forwarded-proto')
• Tune Node HTTP server timeouts (requestTimeout=0, keepAliveTimeout=75s) so slow mobile video uploads aren't killed mid-transfer (was causing uploads to stall at random % and restart from 0)
• Add stale-upload cleanup: retried TUS create POSTs for artifacts whose earlier attempt aborted (ECONNRESET) no longer 409 forever; token-gated so only the upload's own capability token can trigger cleanup
• Persist upload reservations in Mongo (pulsevault_reservations, 24h TTL) instead of an in-memory Map so a server restart between upload-finish and attachment-creation doesn't orphan the file
• Finalize orphaned 'ready' uploads that never got attached
• Fix pulsevault.reserve reusing a completed existingVideoid from the client's stale localStorage cache, which caused the same video to be re-attached to a ticket on every QR re-scan and 409'd real new uploads

[github-actions]

🗑️ Preview Environment Cleaned Up

The preview container for this PR has been deleted.

[kadenhorner]

@morepriyam to review

[jlocala1]

Looks good. I checked the x-forwarded-proto claim against @tus/server's HeaderValidator (it really does strict equality on "http"/"https") and the resolve() semantics against pulsevault 0.1.1, and both hold up. Two things I'd like addressed before this lands, the first ideally in this PR since it touches exactly this code.

1. pulsevault.reserve still doesn't check ownership of existingVideoid

Any signed-in user can pass an arbitrary existingVideoid and get a valid capability token minted for it. That was already true before this PR, but the stakes are higher now: that token also authorizes the new stale-cleanup path, so a token minted for someone else's in-progress artifactId can storage.remove() it out from under them. persistReservation also overwrites the reservation with the caller's userId, so a finished upload could get attached to the wrong user's ticket. Since this PR already special-cases existingVideoid, I'd suggest: when a reservation already exists for that id (in the Map or Mongo), verify reservation.userId === identity.userId before reusing it or minting a token, otherwise mint fresh.

2. The stale-cleanup can't tell "aborted" apart from "still uploading"

resolve() returning null is true both for a dead upload and for one that's actively streaming its PATCH. If the client retries eagerly, or the user re-scans the QR while the original transfer is still draining, the cleanup deletes the in-flight upload's state mid-write. I'd suggest age-gating the removal: only clear the stale state when the upload's file or sidecar mtime is older than a few minutes, so a genuinely active transfer can't get swept.

Happy to re-review quickly once those are in, the rest of this looks good to go.