Palette entries can live beside their screen: cloud, domains and owner move out of src/tui/forge.ts #7731

For: a new terminal screen should add its palette entry in its own module, so src/tui/forge.ts stops holding work back. This issue proves the pattern on three entries only.

Done:

• [ ] a new src/tui/screens/entries.ts exports a PaletteEntry type (id, title, hint, offered(session): boolean, run(session, ctx)) and one ordered list ENTRIES
• [ ] src/tui/screens/cloud.ts, domains.ts and owner.ts each export an entry; ENTRIES names those three in that order
• [ ] forgeCommands in src/tui/forge.ts replaces its three hand-written cloud/domains/owner pushes with one loop over ENTRIES at the same position; every other entry stays where it is
• [ ] test/palette-roster.test.ts passes unchanged — same ids, titles, hints, order, for every session

Files: src/tui/forge.ts, src/tui/screens/entries.ts (new), src/tui/screens/cloud.ts, src/tui/screens/domains.ts, src/tui/screens/owner.ts. Nothing else: no README, no docs, no formatter run over the tree (try 1 of #7299 touched 182 files and its deploy failed). Risk: an import cycle between forge.ts and screens; entries.ts imports screens, forge.ts imports entries.ts, never the reverse.

Parked by the crew: the run ended without a pull: pushed mason/7731-palette-entries-can-live-beside-their-sc but could not open a pull (nothing_to_merge)