fix(worker): degrade gracefully when analytics file is empty

[Androz2091]

A user reported `UNKNOWN_ERROR` for package `14be73071701467d3aae144ab2e72f86`. CloudWatch:

```
File "/app/tasks.py", line 429, in read_analytics_file
print(f'Average compute time per line: {sum(compute_time_per_line) / len(compute_time_per_line)}')
ZeroDivisionError: division by zero
```

Two interacting bugs:

1. Crash: the averaging print divides by `len(compute_time_per_line)`. When the package's analytics file path exists in the zip but the file is empty, the for-loop runs zero times, the list stays `[]`, and the print explodes → relabeled as `UNKNOWN_ERROR`.
2. `is_partial` lie: `is_partial` was set to `False` the moment a file path was found, regardless of whether the file had any events. So even avoiding the crash above, the run would have been called successful with all-zero activity stats.

This shows up when the user un-ticks Activity history in Discord's export request form. Discord ships an empty analytics file rather than omitting the path.

Why graceful instead of erroring

I initially shipped this as a `MISSING_ACTIVITY_DATA` hard error (analogous to `MISSING_USER_DATA` from #80) and a matching frontend copy in dumpus-app/dumpus-app#422. On reflection that's the wrong call: a Discord re-export takes ~30 days, and the user's package still has real value without analytics:

• ✅ Owner profile + avatar (`user.json`)
• ✅ Server list + names (`servers/index.json`)
• ✅ Friends / DM partners
• ✅ Payments / Nitro spent
• ✅ Per-channel message counts (CSV-derived, not analytics-derived)

What's lost: daily-sent-messages chart, sending-times-by-hour, sessions, voice sessions, top items ranked by activity. Asking the user to throw away the rest for a month-long round-trip is unkind.

Fix

```diff
if analytics_file_name:

•        is_partial = False
  

•        compute_time_per_line = []
         for line in TextIOWrapper(zip.open(analytics_file_name)):
             …
  

•        print(f'Average compute time per line: {sum(compute_time_per_line) / len(compute_time_per_line)}')
  

•        if analytics_line_count > 0:
  

•            is_partial = False
  

•            print(f'Average compute time per line: {sum(compute_time_per_line) / len(compute_time_per_line)}')
  

•        else:
  

•            print('Analytics file is empty — keeping is_partial=True; activity-driven stats will be N/A on the client.')
  

```

`is_partial` defaults to `True` at the top of `read_analytics_file` (line 152). It was being incorrectly flipped to `False` before we knew whether the file had real events. Fix: only flip to `False` when we actually parsed at least one event.

Companion frontend work (separate concern, not this PR)

The SQLite output already has `package_data.package_is_partial`. Whether the frontend currently renders activity-driven stats gracefully when partial is its own thread — tracked by dumpus-app/dumpus-app#232 ("Add a banner informing users that some stats are missing"). The bare minimum is that nothing crashes; the polish is showing N/A on the activity-only screens.

The `MISSING_ACTIVITY_DATA` frontend PR (dumpus-app/dumpus-app#422) is no longer needed and will be closed.

Test plan

• Merge → CI deploys.
• Re-submit the failing package — expect it to PROCESS successfully (no UNKNOWN_ERROR) with `is_partial=true` in the resulting SQLite.
• Open the package in the web app — sanity-check that activity-driven screens render without crashing (they may show empty/zero values until #232 lands).
• No regression on packages with real activity data: `is_partial` resolves to `false`, all screens populate.