The terminal's deploys screen lets a writer see who a private app names with `m`, and add or remove one after a plan, as MCP `app_members` does #7418

Intent: the owner hands a private app to a client from the terminal. The client is let in by name without a browser.

This replaces #7287. That issue reached the screen through a new palette entry in src/tui/forge.ts, a file that is in too many open pulls. Both of its tries went red on an unrelated merge-queue test, not on their own code.

Done:

• [ ] On the deploys screen (src/tui/screens/deploys.ts), m on a private app opens a new src/tui/screens/appmembers.ts. It lists the people the app names, read through readAppMembers (src/actions/app_members.ts). A public app is not offered m.
• [ ] On that screen, a asks for a username and d removes the selected person. Each shows the plan (who is let in or out) and applies it only after a confirm, through setAppMembersThrough. An unknown username is refused in the words MCP app_members uses.
• [ ] Only a writer who is a person is offered a and d. An agent sees the list and changes nothing.
• [ ] A new test/tui-appmembers.test.ts proves the round trip: after a confirm, an added person can read the app; after removal, they cannot. It also checks that an agent has neither key and that a public app has no m.
• [ ] The deploys screen's key hints add m members when it is offered.

Files: src/tui/screens/deploys.ts, src/tui/screens/appmembers.ts (new), test/tui-appmembers.test.ts (new). Does not add a palette entry.

Risk: low, since it reuses the action and its refusals.