Fix Containers tab completeness and activity stream events

[mkaltner]

Problem

• The Android Containers tab only loaded the default paginated /containers response, so local search/filter/sort ran against a subset of the active environment's containers.
• Current origin/main also fails Debug Kotlin compilation with the latest SDK because ActivityStreamEventType.ERROR and HEARTBEAT are not handled exhaustively.

Cause

• ContainerListScreen called client.containers.list(envId = envId) without an explicit pagination query, leaving the server default limit in place.
• ActivityCenterStore only handled the older activity stream event variants.

Fix

• Request the full active-environment container list with SearchPaginationSort(start = 0, limit = -1) before applying local filters and sorting.
• Surface stream ERROR frames through the existing stream error state and treat HEARTBEAT frames as no-op keepalives.

Verification

• git diff --check origin/main..origin/fix/containers-complete-list-activity-stream
• ANDROID_HOME=/home/nameless1/Android/Sdk ANDROID_SDK_ROOT=/home/nameless1/Android/Sdk ./gradlew --no-daemon :app:compileDebugKotlin
• ANDROID_HOME=/home/nameless1/Android/Sdk ANDROID_SDK_ROOT=/home/nameless1/Android/Sdk ./gradlew --no-daemon :app:testDebugUnitTest
• ANDROID_HOME=/home/nameless1/Android/Sdk ANDROID_SDK_ROOT=/home/nameless1/Android/Sdk ./gradlew --no-daemon :app:assembleDebug

Disclaimer Greptiles Reviews use AI, make sure to check over its work.

To better help train Greptile on our codebase, if the comment is useful and valid Like the comment, if its not helpful or invalid Dislike

To have Greptile Re-Review the changes, mention greptileai.

Greptile Summary

This PR fixes two separate issues: the Android Containers tab now requests all containers with an explicit pagination query before applying local filters, and ActivityCenterStore adds exhaustive when branch coverage for the ERROR and HEARTBEAT stream event types that caused a Kotlin Debug compilation failure.

• ActivityCenterStore.kt: ERROR frames are surfaced through the existing streamErrorMessage state; HEARTBEAT and UNKNOWN are treated as no-ops. The change is minimal and correct.
• ContainerListScreen.kt: The containers.list call now passes SearchPaginationSort(start = 0, limit = -1). The value -1 is used nowhere else in the codebase — every other SearchPaginationSort call uses an explicit positive limit (100–500). WebhooksScreen.kt fetches the same endpoint with limit = 500. If the API does not honour -1 as "unlimited," the Containers tab will enter an error state or return a silently incomplete list.

Confidence Score: 4/5

Safe to merge after confirming the API accepts limit = -1 as an unlimited sentinel; the ActivityCenterStore fix is clean and ready.

The ActivityCenterStore change is correct and straightforward. The ContainerListScreen fix correctly identifies the root cause (missing explicit pagination), but limit = -1 is the only negative limit value used anywhere in the app — every other screen caps at 100–500. If the backend or SDK does not treat -1 as fetch all, the Containers tab will silently remain broken or show an error on load.

ContainerListScreen.kt — the limit = -1 value needs confirmation against the SDK/API contract before merge.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
app/src/main/kotlin/app/getarcane/android/ui/screens/containers/ContainerListScreen.kt:100
**`limit = -1` unsupported across the rest of the codebase**

Every other `SearchPaginationSort` call in the app uses a positive limit (100, 200, 500, or an explicit page size). Notably, `WebhooksScreen.kt` calls the same `client.containers.list` with `limit = 500` as its "full load" approach. `limit = -1` is unique to this PR and there is no evidence from the SDK or any other call site that the server treats `-1` as "unlimited." If the API instead treats `-1` as invalid, a zero-page default, or throws an exception, the result is a broken Containers tab (error state or silently empty list) rather than the intended complete load. Aligning with the rest of the codebase and using a high explicit cap (e.g., `limit = 500`) would be safer until confirmed that the API honours `-1`.

_{Reviews (1): Last reviewed commit: "Load all containers in Containers tab" | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[mkaltner]

Greptile's limit = -1 concern is answered by the Arcane backend contract: backend/api/handlers/helpers.go documents limit = -1 as "show all items" / no pagination, and the grouped container pagination tests model limit === -1 as returning the full container set with itemsPerPage = containers.length. So the Containers tab request is using the server's intended unlimited sentinel rather than an arbitrary Android-only value.