Three related problems that belong together:
1. App state is scattered across three files. rustpg.conf holds settings, a separate recent file holds the recent-file list, and window size/position is not persisted at all. These should live in one place. Option A: fold everything into rustpg.conf (recent01=... through recent10=; window_w, window_h, window_x, window_y). Option B: keep rustpg.conf for user-visible settings and add rustpg.state for ephemeral runtime state. Either way, the recent sidecar file goes away.
2. App metadata leaks even when key material is encrypted. An attacker with read access to ~/.config/rustpg/ can see the recent-file list (what documents you opened) and the my_id setting (reveals your identity slug, which is a hint about the contents of key_material.rpg). If rustpg.conf were encrypted with the same key as key_material.rpg, this metadata would be protected at the same trust boundary as the keys themselves.
3. App password at startup. A natural extension of point 2: require the master password before the app renders anything (the red passphrase box appears first). On first run it is set and asked twice. A Settings → Change app password menu item replaces the current Change master password item. This unifies key material and app state under one password and ensures nothing is ever written unencrypted, including metadata. The current flow already has the machinery — it is a matter of applying it earlier in startup.
The menu item to view rustpg.conf in the main window (original request) is still wanted regardless of which option is chosen — useful on Windows where the config path is non-obvious.