native: swipe through sibling posts in gallery

[davidisaaclee]

Adds the ability to swipe through posts in a gallery PostScreen.
There are some other UI and behavior changes added by @dnbrwstr (see the first commit in this PR) – most visible is changing gallery text posts to have a square frame and $secondaryBackground background fill.

The view tree is roughly like this now:

<PostScreen>
  <KeyboardAvoidingView>
    <Header />
  
    {isCarousel ? (
      <PostCarousel posts={siblingsOf(parentPost)}>
        {eachPost => <SinglePostView post={eachPost} />}
      </PostCarousel>
    ) : (
      <SinglePostView post={parentPost} />
    )}
    
    <ReplyInput />
  </KeyboardAvoidingView>
</PostScreen>

This is a big diff because

• PostScreenView had a lot of baked-in assumptions about displaying a single post (which, in a carousel setting, would affect basic operation and would incur more loads than needed)
• PostScreenView receives a big bundle of props, many of which also assumed that it was only operating on a single post

Highlights:

• I pulled much of the single-post logic into SinglePostView
• There were a lot of passed props that could've been pulled into SinglePostView, but would've made an even huger diff:
  • some props could just be pulled from contexts in the child, like navigation callbacks
  • there are a lot of props pulled from a single useChannelContext at PostScreen: I could move this into SinglePostView, but I see that there is state managed in useChannelContext, and I don't know how managing multiple instances of this hook would work. (I think we should add an explicit provider for this "context," maybe the existing ChannelContext, and share state within the subtree.) For these props, I just pulled them into a channelContext object so I could pass them around easily and hopefully aid clean up later.

Screen recordings

CarouselPostScreenContent fixture (demonstrating that loading more posts should maintain scroll position)

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-03-06.at.10.59.44.mp4

Swiping in real gallery; sending replies; following refs from/to gallery
https://github.com/user-attachments/assets/8ca62b5b-32c4-4c19-8136-5b8a4310e12e

I noticed these bugs / weird behavior which are also present in the most recent release:

• Following a ref from gallery post to a reply on a gallery post loads just that reply by itself
• Sending a reply in a gallery thread does not autoscroll to the new message
• Following a ref from a gallery reply to another reply in that same thread fails to scroll to that reply (code existed for this but doesn't work)

[davidisaaclee]

emphasizing this comment – realizing now that I think this breaks saving drafts per thread. going to investigate more now!

[jamesacklin]

Makes sense to me, thank you

[davidisaaclee]

after investigating: I tried changing the draftKey of useChannelContext based on the focusedPost – this doesn't work, and just loads the same draft for all threads in the carousel:

this is because we load the draft using getDraft on mount (around here). it'll be tough to separate the drafts per thread – we'll need to either:

1. defer draft load until user has swiped to that thread (I think this would lead to bad UI and bugs)
2. move the useChannelContext call into the SinglePostView context – i.e. do one useChannelContext per thread

I'm going afk for a few hours but I can investigate having multiple useChannelContexts when I get back. going to open review but I understand if this is a blocking regression.

[davidisaaclee]

Drafts not being saved in their respective thread was not caused by editingPost, but by the get/store/clearDraft callbacks – fixed in ccc7c34 and 4c4b211

I think we can punt on editingPost because we don't allow editing in any carousel contexts (i.e. galleries).

Tested by drafting some replies in different threads of the same gallery, exiting app, returning, seeing that the threads had the correct drafts saved.
I also checked that editing a notebook post and saving worked; and that editing a notebook post and tapping "back" correctly discards the edit (i.e. it doesn't post the edit, it reverts to the original post when starting a second edit after dismiss).

[davidisaaclee]

emphasizing (will delete before merge)

[latter-bolden]

Agree it's not working for refs in the same thread. Even with this commented out, ref clicks appear to behave the same as on develop. I think this can be removed.

[davidisaaclee]

emphasizing (will delete before merge)

[latter-bolden]

I'm fine removing for now

[latter-bolden]

Pending passing CI and removing those noted comments, I think this is good to go.

The FlatList approach is interesting, wouldn't have guessed that's how it's wired up. Appreciate the featureful fixtures.