test(tui): stabilize async app server tests

[viyatb-oai]

Why

Several TUI tests drive the embedded app-server through async request paths. Running those cases on the shared async test runtime makes them sensitive to scheduling and stack pressure, which adds noise to TUI CI while permission-profile work is being reviewed.

What changed

• Run the affected embedded app-server TUI tests on dedicated single-worker runtimes.
• Give the few stack-heavy cases an explicit test runtime stack size.
• Keep the existing assertions and request coverage intact while isolating the runtime setup from unrelated async tests.

Validation

• GitHub CI for this PR.

Context

Split out of #21559 so the permission-profile picker PR stays focused on its product change.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cfca364ce5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Run the test body on the resized stack

When stack pressure comes from the async test body itself, this thread_stack_size does not protect it: Tokio documents this as the stack size for worker threads, and the multi-thread scheduler's Runtime::block_on executes the supplied future on the current test-harness thread while only spawned tasks run on the worker pool. The converted tests all pass their large async bodies directly to runtime.block_on(...), so those stack-heavy paths still use the default test thread stack and can keep overflowing/flaking; wrap the whole test in a std::thread::Builder::stack_size(...) thread or spawn the body onto the runtime before awaiting it.

Useful? React with 👍 / 👎.