fix(channels): read metadata for a labeled channel whose roster came first

[loganj]

🤖

Summary

• Looking up a channel by its creator and label (for example, a plugin finding its records channel) could intermittently return nothing for a channel the viewer had just been added to.
• Cause: the app first learns which channels the viewer belongs to, and reads their names and labels a moment later. If a lookup ran in that short window, the app treated the channel as already known, skipped re-reading it, and then dropped it because it had no labels yet.
• The lookup now re-reads such a channel. Search and other callers keep their current behavior.

Details

• findLabeled passes a new unnamed flag to resolve, which then also reads authorized channels whose metadata has not arrived. The flag is local to the lookup because search and membership hints rely on the existing filter (their tests read exactly the channels they expect).
• The evidence points to the app, not to relay replica lag. The fix changes only what the app does after the relay answers the label query, and it removed the misses on staging (see Testing). A lagging relay answer would still miss with the fix.

Related issue

None found. Found while testing system channels on staging.

Testing

• New unit test in store-discovery.test.ts puts the store in that window (roster known, metadata not yet read) and checks the lookup finds the channel. It fails without the fix.
• Against the staging relay, with the lookup run right after the channel appeared (and before its labels arrived, in every run): without the fix 1 of 8 lookups returned nothing; with the fix 32 of 32 found the channel.