[stormer78]

Closes #533

Moves each main-page panel's key handling out of openvtc/src/ui/pages/main/mod.rs and puts it next to that panel's rendering. This is a mechanical move. No behaviour changes. Review it with git show --color-moved=zebra --color-moved-ws=allow-indentation-change.

What moved where

Handler / helper	New home
handle_vta_key	components/vta_panel.rs
handle_personas_key	components/identity_panel/keys.rs (new)
handle_capabilities_key	components/capabilities_panel.rs
handle_communities_key, handle_context_delete_key, handle_device_access_key, personhood_evidence_key (+ personhood_evidence_key_tests)	components/communities_panel/keys.rs (new)
repos_key, repos_copy_path	components/repos_panel/keys.rs (new)
rooms_key	components/rooms_panel.rs
elections_key	components/elections_panel.rs
handle_inbox_key	components/inbox_panel.rs
handle_relationships_key	components/relationships_panel.rs
handle_credentials_key	components/credentials_panel.rs
handle_settings_key, handle_config_form_key, passphrase_problem	components/settings_panel.rs
handle_logs_key	components/logs_panel.rs
handle_help_key	components/content_panel.rs (where Help is rendered)
handle_vetting_key	components/vetting_panel/keys.rs (new)

Four component files were already large: identity (3,962 lines), vetting (3,059), repos (2,397) and communities (1,634). Each of these gets a keys submodule (<panel>.rs + <panel>/keys.rs) instead of growing further. The smaller panels take their handler at the end of the component file, before its tests.

The methods stay impl MainPage blocks, because impl blocks can live in any module of the crate. Child modules of main can already see MainPage's private fields and mod.rs's private helpers. Because of that, the only edits are:

• use lines.
• Visibility: pub(in crate::ui::pages::main) where mod.rs calls the item, pub(super) where only a sibling under components calls it, and private otherwise. repos_panel::keys is pub(in crate::ui::pages::main) because the communities keys and the mod.rs tests reach into it.
• Two misplaced doc comments reattached to the items they describe (see the list below).
• //! headers on the files that lacked one.

Staying in mod.rs

• Global routing in handle_key_event: the overlays, Ctrl+K, F10, Tab/←/→, and ↑/↓/Enter on the menu.
• The handle_content_key_event scroll keys and the dispatch-by-menu match.
• The overlay handlers: create-persona, agent-name manager, add-VIC and switcher. Their render functions live in mod.rs too.
• handle_paste_event with repos_paste and grant_form_text.
• Shared helpers: edit_text, copy_to_clipboard.
• key_handler_tests. It drives the public handle_key_event entry point across every panel and shares one set of fixtures, so splitting it per panel would mean restructuring it rather than moving it. That is left for a follow-up.

Layout (lines)

File	Before	After
main/mod.rs	7,180	4,312 (≈2,880 of that is key_handler_tests)
components/capabilities_panel.rs	240	287
components/communities_panel.rs	1,634	1,639
components/communities_panel/keys.rs	–	535
components/content_panel.rs	354	420
components/credentials_panel.rs	464	644
components/elections_panel.rs	786	863
components/identity_panel.rs	3,962	3,964
components/identity_panel/keys.rs	–	411
components/inbox_panel.rs	403	566
components/logs_panel.rs	101	173
components/relationships_panel.rs	883	1,221
components/repos_panel.rs	2,397	2,399
components/repos_panel/keys.rs	–	239
components/rooms_panel.rs	209	227
components/settings_panel.rs	924	1,377
components/vetting_panel.rs	3,059	3,061
components/vetting_panel/keys.rs	–	262
components/vta_panel.rs	1,074	1,182

Verification

• cargo fmt --all --check passes.
• cargo clippy --workspace --all-targets --locked -- -D warnings passes, with and without --no-default-features.
• cargo clippy -p openvtc --all-targets --features dev-overrides -- -D warnings passes.
• RUSTDOCFLAGS='-D warnings' cargo doc --workspace --no-deps passes.
• cargo test --workspace --locked passes, with and without --no-default-features.
• openvtc bin unit tests: 1051 before → 1051 after, with default features and with --no-default-features.
• No service calls were added or changed, so the vti-stack-development-guide.md networking checklist doesn't apply.

Key-handling problems noticed but not fixed (input for the UX PR)

1. Doc comments on the wrong item. The "Communities overview keys" doc sat on top of handle_capabilities_key, and edit_text's doc sat on the vetting impl MainPage block. Both are reattached in this PR because a move would otherwise carry them to the wrong file. view_id's doc comment is still attached to wrap_text in mod.rs (not touched).
2. The communities doc is stale. It says "d/Del removes the selected community". d/Del only arms a delete for inactive rows; for an Active row you leave with l first. The doc lists 3 of the roughly 20 verbs.
3. Confirmation keys differ between panels. VTA VIC delete/purge, capabilities toggle, agent-name remove, inbox, and communities delete/leave/withdraw accept y or Enter. Repos, workspace, elections cast/disclose and the personhood "include all" accept only y, on purpose, so a held Enter can't confirm. Pick one rule.
4. Comments promise one cancel key, but any key cancels. The communities comment says "cancel (n/Esc)", but any key other than y/Enter cancels. Comments and help text that name a single cancel key should be checked against the code.
5. j/k mean different things. In Communities, j starts a join. In the sub-views opened from it (capabilities, rooms, elections list and ballot), j/k move down/up. Repos, VTA, inbox, relationships, logs and the switcher have no j/k at all.
6. r changes meaning between levels. On the Communities list r opens Repos; inside every sub-view (capabilities, rooms, elections, repos) r refreshes.
7. c has two jobs on the Communities list. It opens capabilities on an Active row and arms withdraw on a Pending row. The row state decides which one fires.
8. Some keys are swallowed with no feedback. VTA u returns "handled" even when the selected VIC is neither Archived nor Deleted. Help 3/4 return "handled" when no did-git-sign info exists. Nothing is shown to the user in either case.
9. Esc doesn't do the same thing everywhere. Top-level panels send MainPanelSwitch(MainMenu). Sub-views send their own Back/Close. Logs detail closes on Esc or Enter.
10. Logs keeps its own state. logs_selected and logs_detail_view live on MainPage, not in State, unlike every other panel. Nothing clamps logs_selected when the log shrinks.
11. Some panels don't take paste. handle_paste_event routes paste for relationships, credentials, vetting, settings and communities only. The create-persona and agent-name-manager overlays have text inputs but ignore paste with no indication.
12. Issue refactor(ui): move per-panel key handling out of ui/pages/main/mod.rs (7k lines) into the panel components #533's suggested shape is not done yet. That shape is pure KeyEvent -> Option<Action> per panel, with footer text generated from the same table. Only rooms_key, elections_key, repos_key and personhood_evidence_key already work that way. The rest still call action_tx.send directly (about 200 call sites).