[Linux/niri] Launch hotkeys written into user's compositor config without consent; no supported way to remove

On Linux, jcode silently installs its global "launch hotkeys" into the user's
compositor configuration file without asking for consent first.

For niri, on the very first launch, maybe_show_setup_hints()
(crates/jcode-setup-hints/src/lib.rs) sees that hotkeys are not installed yet
and [launch_hotkeys].enabled is unset (which defaults to enabled), so
linux_hotkey_setup_action() returns Install and
install_niri_launch_hotkeys() rewrites ~/.config/niri/config.kdl,
splicing a managed block straight into the user's binds { } section:

binds {
    // >>> jcode launch hotkeys (managed) >>>
    Super+Semicolon hotkey-overlay-title="jcode: home" { spawn "sh" "-c" "… --spawn-hotkey 'cmd+;'"; }
    Super+Apostrophe hotkey-overlay-title="jcode: last project" { spawn "sh" "-c" "… --spawn-hotkey 'cmd+\''"; }
    Super+Shift+Apostrophe hotkey-overlay-title="jcode: self-dev (self-dev)" { … }
    // <<< jcode launch hotkeys (managed) <<<
}

The default bindings are hard-coded in
launch_hotkeys.rs::default_launch_entries() (cmd+;, cmd+', cmd+shift+'),
and rendered for niri in linux_niri.rs (chord_to_niri_bind maps cmd → Super).

Why this is a problem

1. No consent / no opt-in. A tool modifying the user's WM/compositor config
   is a surprise. The user did not ask for global hotkeys, may already have
   those chords bound, or may not want jcode to touch their config at all.
2. No supported way to undo it. jcode setup-hotkey --uninstall on Linux is
   a no-op — uninstall_linux_launch_hotkeys() just returns
   "automatic launch-hotkey removal is not supported for this Linux desktop".
   The only way to revert is to edit the compositor config by hand.
3. No prompt, even at install time. [launch_hotkeys].enabled = false
   disables future installs, but that requires the user to already know about
   the option; nothing asks them during first run.
4. Preconfigured niri setups already have a proper config structure.
   Real-world, preconfigured niri setups (common presets, distro-tuned
   dotfiles, etc.) typically keep the top-level config.kdl clean and split
   functionality into separate files via include "./cfg/*.kdl". jcode ignores
   that layout entirely and splices its block straight into the main config
   file — forcing a flat, "just dump it into the root file" structure that is
   simply out of place and harms the maintainability of the user's config.

Expected behavior

• Hotkey setup should be opt-in: do not modify any system/user compositor
  config until the user explicitly asks (e.g. via jcode setup-hotkey) or
  confirms during first-run onboarding.
• If installing, prefer a dedicated include file or clearly separated
  section rather than splitting a user-authored config.
• Provide a working Linux uninstall path that removes the managed block.
• Ideally detect conflicts with existing bindings before installing.

References

• crates/jcode-setup-hints/src/lib.rs:
  linux_hotkey_setup_action(), install_niri_launch_hotkeys(),
  linux_launch_hotkeys_notice(), uninstall_linux_launch_hotkeys()
  (the no-op that bails on Linux).
• crates/jcode-setup-hints/src/launch_hotkeys.rs: default_launch_entries().
• crates/jcode-setup-hints/src/linux_niri.rs: render_niri_block(),
  NIRI_BLOCK_BEGIN/NIRI_BLOCK_END, splice_managed_block().
• Related cosmetics: the installed-notice is a single long line
  (linux_launch_hotkeys_notice joins entries with "; "), which wraps/clips
  poorly in the TUI.

Environment

• OS: Linux (CachyOS), compositor: niri
• jcode v0.80.1; first launch auto-installed the bindings without asking.

Start with maybe_show_setup_hints(), linux_hotkey_setup_action(), and uninstall_linux_launch_hotkeys() in crates/jcode-setup-hints/src/lib.rs, then read render_niri_block() and splice_managed_block() in linux_niri.rs. Trace the existing first-run install and Linux uninstall paths, including default_launch_entries() in launch_hotkeys.rs. Done means installation is opt-in, niri configuration handling respects the stated structure, and Linux removal works for the managed block.