An admin deletes a repository from the terminal's `:` palette after typing its full name, as Settings' Delete this repository does #8031

Intent: cutting the noise for good works from the terminal too; today only Settings' danger zone (and the API) reach deleteRepo in src/actions/repos.ts, and the terminal has no way to delete a repository.

Done looks like:

• [ ] A new src/tui/screens/deleterepo.ts exports deleteRepoCommands(f, ctx, repo) in the shape of yoursCommands in src/tui/screens/yours.ts: for a repository admin who is a person, one command titled <owner>/<name> — Delete this repository (the words from DELETE_REPO in src/web/danger_words.ts), hint "cannot be undone"; nothing for anyone else.
• [ ] Running it opens promptScreen (as the Cloud screen's x does): the label says what goes ("every issue, pull request, comment and webhook, and the git objects; forks are detached first and keep working") and asks to type <owner>/<name>; anything else is refused with "Type <owner>/<name> to confirm." and nothing changes.
• [ ] The exact name calls deleteRepo(f.app, f.user, repo), toasts "deleted <owner>/<name>" or the refusal, and leaves the repository's screens for the previous one that still exists.
• [ ] src/tui/screens/workspace.ts adds ...deleteRepoCommands(f, ctx, repo) directly after ...yoursCommands(f, ctx, repo) and its import beside ./yours.ts's.
• [ ] A new test/tui-delete-repo.test.ts proves: an admin who types the name deletes the repository; a wrong name keeps it; a writer who is not an admin and an agent are not offered the command. It fails without the change.

Files: src/tui/screens/deleterepo.ts, src/tui/screens/workspace.ts, test/tui-delete-repo.test.ts Risks: the screens under the deleted repository must not read it again after it is gone; pop back before re-rendering. Brief: a builder who knows the terminal screens.