fix(worker): surface EXPIRED_LINK / INVALID_LINK instead of UNKNOWN_ERROR

[Androz2091]

Summary

Two interacting bugs were causing every link-download failure to surface as `UNKNOWN_ERROR`, including the very common case of a Discord link that expired before the worker picked it up.

Bug 1: download_file treated 4xx as `INVALID_LINK`

`click.discord.com` 302s to a Google Cloud Storage signed URL. Once the signature TTL is up (Discord exports expire fairly quickly), the GCS URL returns `HTTP 400`. The old code:

```python
if r.status_code != 200 or 'content-type' not in r.headers or 'application/octet-stream' not in r.headers['content-type']:
raise Exception('INVALID_LINK')
```

…raised `INVALID_LINK`, which was wrong — the link wasn't malformed, it was expired.

Bug 2: `process_package` masked everything except EXPIRED_LINK

```python
expected = ('EXPIRED_LINK') # ← this is a STRING, not a tuple!
if expected not in current:
current = 'UNKNOWN_ERROR'
```

Python tuples need a comma: `('EXPIRED_LINK',)`. The intended single-element tuple is just the bare string. The `in` check then accidentally did substring match on a single code — so even when the worker raised `INVALID_LINK`, the route relabeled it `UNKNOWN_ERROR`.

Fix

• HEAD returns 4xx → raise `EXPIRED_LINK` (verified: the user's example expired link returns `HTTP 400` from the GCS redirect target).
• Wrong status / missing or wrong content-type → `INVALID_LINK`.
• Anything else → `UNKNOWN_ERROR` with the full traceback preserved.
• `EXPECTED_ERROR_CODES` is now a proper tuple of both known codes.

Verified against a real expired link

```
$ curl -sS -I -L "<user's example expired upn>"
HTTP/2 302 ← click.discord.com
location: https://storage.googleapis.com/discord-harvest-prd/.../package.zip?...

HTTP/2 400 ← GCS, signature expired
```

So `requests.head(link, allow_redirects=True).status_code` is `400` for an expired link → my new branch catches it and raises `EXPIRED_LINK`.

Frontend follow-up (separate)

The frontend's status-response type doesn't currently list `INVALID_LINK` as a possible `errorMessageCode` (only the four: UNKNOWN_PACKAGE_ID, UNKNOWN_ERROR, UNAUTHORIZED, EXPIRED_LINK). If we want the friendly "Link expired" copy to render for INVALID_LINK too, that's a one-line type widening in dumpus-app — happy to open it as a follow-up PR.

Test plan

• Merge → CI deploys.
• Submit the user's example expired link via `/process`. Expect status to settle on `isErrored: true, errorMessageCode: 'EXPIRED_LINK'` (not `UNKNOWN_ERROR`).
• CloudWatch should show `Link is expired (upstream returned 400).` instead of `The link does not point to a valid file.` for these.