Two issues found while setting up the watcher on macOS 26.1

# Two issues found while setting up the watcher on macOS 26.1

**Repository:** ActivityWatch/aw-import-screentime
**Commit:** `1297039` (2026-07-27)
**Host:** macOS 26.1 (build 25B78), Apple Silicon, Python 3.13 via uv
**Source device:** iPad (iPadOS), Screen Time "Share Across Devices" enabled

Thanks for building this — it is the only working route for iPadOS usage data that I
found. Two problems came up during setup; both have small fixes.

---

## 1. `watch` hardcodes `platform=2` and silently imports nothing

`devices` and `events` both expose `--platform` (default 2), but `watch` does not, and
calls:

```python
# src/aw_import_screentime/__main__.py
all_ids = get_device_ids(SYNC_DB_PATH, platform=2)
```

On this machine the iPad peer is recorded in `~/Library/Biome/sync/sync.db` with
`platform = 1`, not 2:

```
$ sqlite3 sync.db 'SELECT device_identifier, me, model, platform FROM DevicePeer'
|1|25B78 |4 <- this Mac (macOS 26.1, build 25B78)
|0|22H352|1 <- the iPad
```

Accordingly:

```
$ aw-import-screentime devices
INFO Found 0 device(s) for platform 2
[]

$ aw-import-screentime devices --platform 1
INFO Found 1 device(s) for platform 1
[{"device_id": "", "path": ".../App.InFocus/remote/"}]
```

The failure mode is quiet: `watch` starts, logs "Found 0 device(s)", waits forever and
never imports anything. Nothing indicates that a device exists but was filtered out.

I don't know whether the platform code varies by macOS version, by device type, or by how
the peer was first registered — but since the value clearly isn't stable, hardcoding one
value seems risky.

**Suggested fix:** probe both, or expose `--platform` on `watch` as well. What I ran
locally:

```python
# Some hosts record iOS/iPadOS peers as platform 1 rather than 2.
all_ids = list(
dict.fromkeys(
get_device_ids(SYNC_DB_PATH, platform=2)
+ get_device_ids(SYNC_DB_PATH, platform=1)
)
)
```

A warning when devices are found under a *different* platform than the one requested
would also have saved me a while.

---

## 2. Sync gaps produce single events spanning days

`stitch_intervals_with_state` closes an interval when the next event for that device
arrives. If the source device stops syncing while an app is in the foreground, the
closing event only appears once syncing resumes — so the resulting interval covers the
entire gap.

Concretely, on a first import over 30 days I got:

```
189.79 h <- sync gap, not usage
2.73 h
2.67 h
```

The iPad had stopped syncing with `` frontmost and resumed ~8 days later. That
single event was 85 % of the imported total and inflated the daily average by roughly a
factor of five — enough to make every aggregate in the ActivityWatch UI useless until I
noticed it.

Deleting the event doesn't help: the next `watch` run re-derives it from the source data
and inserts it again.

The README already notes that "macOS sometimes logs incomplete foreground durations;
intervals are stitched best-effort", so this is presumably known — but the unbounded case
seems worth guarding against, because a single artifact dominates everything downstream.

**Suggested fix:** clamp (or drop, or split) intervals beyond a plausible maximum, ideally
configurable. What I ran locally:

```python
MAX_INTERVAL_SECONDS = 6 * 3600

duration = ts - start_ts
if duration.total_seconds() > MAX_INTERVAL_SECONDS:
logger.warning(
"Clamping implausible interval: %s starting %s (%.1fh -> %.1fh)",
current_bundle, start_ts.isoformat(),
duration.total_seconds() / 3600, MAX_INTERVAL_SECONDS / 3600,
)
duration = timedelta(seconds=MAX_INTERVAL_SECONDS)
```

Clamping rather than dropping keeps the signal that the app was in use at that time, while
bounding the error. After the change the same import produced a plausible total
with a 6.00 h maximum, and the warning made the affected interval easy to spot.

Happy to open PRs for either of these if useful.