Fix containers list and activity stream events

[mkaltner]

Summary

• Load the Containers tab with SearchPaginationSort(start = 0, limit = -1) so local search, filter, and sort operate on the complete active-environment container list instead of the server default page.
• Handle new Activity Center stream event kinds: show the stream error message for ERROR, and ignore HEARTBEAT like UNKNOWN, keeping the existing store flow intact.
• Replaces closed PR Load all containers in Containers tab #37 with a clean branch that includes the CI compile fix.

Verification

• git diff --check
• ./gradlew :app:compileDebugKotlin
• ./gradlew :app:testDebugUnitTest

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 makes two targeted fixes: it handles the new ERROR and HEARTBEAT activity stream event kinds in ActivityCenterStore, and it switches the containers list call to SearchPaginationSort(start = 0, limit = -1) so that search, filtering, and sorting all operate on the complete server-side list rather than a default-sized page.

• ActivityCenterStore: ERROR now surfaces event.error (or a fallback string) as streamErrorMessage; HEARTBEAT is silently ignored alongside UNKNOWN. Both are consistent with the existing MISSED handling pattern.
• ContainerListScreen: limit = -1 is passed to containers.list() to request an unbounded result set. This sentinel is not used elsewhere in the codebase, so confirming the SDK accepts it as "return all" would be prudent.

Confidence Score: 4/5

The activity-stream changes are clean and safe to merge. The container list change works correctly as long as the SDK accepts -1 as an unbounded-fetch value, which is the only unverified assumption.

Both changes are small and self-contained. The activity-stream event handling follows the established pattern exactly and introduces no risk. The containers change intentionally fetches the full list, but limit = -1 is not corroborated by any other SDK callsite in the codebase, so there is a small open question about whether the backend honours that sentinel.

ContainerListScreen.kt — specifically the limit = -1 parameter passed to containers.list().

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` as an "unbounded fetch" sentinel is not documented anywhere else in this codebase — other callers use concrete limits (`100` for environments, `PAGE_SIZE = 50` for activities). If the backend SDK or REST API does not recognise `-1` as "return all", the call will fail or silently return 0/1 item, leaving the list empty on every load. Even if it is supported, a very large environment could return a payload that stalls the main-thread recomposition. Confirm the SDK contract accepts `-1` as unlimited, or use a documented "no-limit" constant if one exists.

_{Reviews (1): Last reviewed commit: "Fix containers list and activity stream ..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.