test(resolver): fix flaky edge-batch test that raced the cache write

TestUserResolver_BatchesMissesThroughEdge failed intermittently (~10% of
runs locally, and it just failed CI on #128) with:

    user_resolver_test.go: U001 was not cached from the edge batch:
    getting user: sql: no rows in result set

Same root cause as the membership flake fixed in #171: the test waited
on a barrier that does not gate the state it asserts.

fakeBatcher.UsersInfo records the batch and returns immediately. The
resolver only *then* loops applyEdgeUser, which is what calls
UpsertUserFromEdge. So `for len(batcher.calls()) == 0 { ... }` returned
before any row existed, and the db.GetUser assertions raced the write.

Wait for the applied result instead — both cache rows present and both
UserResolvedMsg sent. applyEdgeUser writes the row and then sends, per
user, so the message count is the later signal and implies every write
has landed. Adds a waitUntil helper to the package and documents why a
batcher call count must not be used as a barrier.

Verified: 40/40 under -race (previously ~2 failures per 20), and it
still fails as intended when UpsertUserFromEdge is stubbed out, so it
has not been weakened into a no-op.