GitHub does support that workflow, if I'm understanding you right.
You can set the target branch on a PR. So pr A targets main, B and C target A. After you merge A, B and C even get automatically retargeted to main (or whatever you merge A into). This handles the "block B and C until A is merged" requirement as well.
Now, you can accidentally merge B and C early by accident into A and mess with the diff, and you need to have your CI properly configured to only check the diff between them and their target (not just main) but it works fine for most use cases in my experience. The other unfortunate thing is the potential for merge conflicts in the stack, of course, if you change A after branching the others off.
What we did to avoid that bottleneck was just turn off the prettier eslint rule in CI and just run the `prettier --check` command they recommend in their docs.
We also have it set to only run in changed files which helps a lot.
We generally don't link pre-commit hooks for standards though, hence the CI focus. Too easy to circumvent, and I'd rather pay for an external machine to check it when it matters (pre-merge by doing it on PR commits) than block my devs when it doesn't (every time they commit to a non-main branch).
You can definitely serve content like that from your server and have the app render it (no website required). The review process would not block that.
You could also serve a change like this with an OTA update, again no app store review required, which ios and android allow (as long as you don't fundamentally change the app, and even then they could only catch that retroactively.
Not sure if they'd care if you load it in a webview as long as the UX wasn't substantially different. I seem to recall getting bounced to web auth flows pretty often.
Also curious how much y'all isolate it from your other infra. I've thought about this but I've been torn on whether I'd set up a separate vpc for it.