Reduce Firestore reads on users & usersStatus collections (avoid full-collection scans)

Description

The main goal of this issue is to reduce the number of Firestore reads on the users and usersStatus collections.

Right now a few of our flows (around 3–4 functions) read far more data than they need to. They scan the entire collection every time, including users who are no longer active, and then do extra per-user lookups on top of that. As these collections grow, this becomes expensive and slow.

The idea is simple: fetch only the active users first, and then do the follow-up work (like checking their tasks/status) on just that smaller set. This cuts down the reads dramatically because we stop scanning the whole table and stop touching users we don't care about.

Current Behavior

• Several flows read the entire users / usersStatus collection, even though only active users are relevant.
• On top of the full scan, they do additional per-user reads (one lookup per user), which multiplies the cost.
• Archived / inactive users are read and processed even though they get filtered out later anyway.
• The result is a high, ever-growing number of Firestore reads on these two collections.

Expected Behavior

• Fetch only the active users up front, instead of scanning the whole collection.
• Do the follow-up actions (task checks, status checks, etc.) only for that active set.
• Read the related data in batches instead of one read per user wherever possible.
• Overall, a significant reduction in Firestore reads on the users and usersStatus collections, with the same end results.

How we plan to fix it

• Change the heavy flows so they start from "active users only" rather than the full collection.
• Replace the per-user lookups with batched reads so we make far fewer round trips.
• Skip archived / inactive users early, so we never spend reads on data we're going to discard.
• Keep the output/behavior of these flows exactly the same — this is purely a read-cost optimization, not a functional change.