fix: use server-computed endsAt for exploration timer to prevent clock drift (#68)

## Summary

- Exploration timers showed more time than the area's stated duration when the server clock was ahead of the client's
- The timer was derived from `startedAt = endsAt - durationMs`, then computed as `durationSeconds - (clientNow - startedAt) / 1000` — any server/client clock skew directly inflated the result
- Now stores `endsAt` (the server-computed completion timestamp) directly in `ExplorationAreaState` and computes the timer as `(endsAt - Date.now()) / 1000`, which is immune to clock drift
- Old saves without `endsAt` fall back gracefully to the previous `startedAt`-based calculation

## Test plan

- [ ] Start a new exploration — timer should show exactly the area's stated duration (no more "1h area shows 1h15m")
- [ ] Refresh the page mid-exploration — timer should resume from the correct remaining time (using server-anchored `endsAt`)
- [ ] Old saves with `startedAt` but no `endsAt` should still display a timer via the fallback path

Closes #53

✨ This PR was created with help from Hikari~ 🌸

Reviewed-on: #68
Co-authored-by: Hikari <hikari@nhcarrigan.com>
Co-committed-by: Hikari <hikari@nhcarrigan.com>

packages/types/src/interfaces/exploration.ts

@@ -72,6 +72,12 @@ interface ExplorationAreaState {
    */
   startedAt?: number;
 
+  /**
+   * Unix timestamp when the exploration will complete (server-computed, used for
+   * accurate client-side countdown that is immune to client/server clock drift).
+   */
+  endsAt?: number;
+
   /**
    * True after the first successful collect — used for codex unlock detection.
    */