Fix: Remove confusing <remap> entry from keypad display

[Kaylebor]

Summary

This PR fixes an issue where the Meow keypad displays a confusing <remap> entry when users press SPC to view available commands.

Problem

When pressing SPC in Meow normal mode, the keypad shows an entry labeled <remap> alongside the actual commands. This entry:

• Is meaningless to users (you can't press a <remap> key)
• Is an implementation detail from suppress-keymap
• Clutters the command palette with non-actionable information

Solution

The fix removes the remap entry from the display keymap after it's built, while preserving the actual key suppression functionality. The remap entry (which prevents character insertion) still exists in the functional keymap, it's just filtered out from what users see.

Testing

1. Enable Meow mode
2. Press SPC in normal mode
3. Verify that no <remap> entry appears in the keypad display
4. Verify that pressing unmapped keys still does nothing (suppression still works)

Technical Details

suppress-keymap adds a [remap self-insert-command] -> undefined entry to prevent character insertion. This is correct behavior for a command keymap, but the entry shouldn't be shown to users as it's not an actionable command.

The fix uses assq-delete-all to remove the remap symbol from the display keymap structure after building it.

[eshrh]

This is probably good... I just have one concern: this is only removing remap in the leader configuration for no modifier keys. Is this correct? For example, in the cases when we have M-, C-M- or literal, we call meow--make-keymap-for-describe which also makes a suppressed keymap. Do we need to add this logic there too?

I guess this perhaps signals a need for better abstraction for making keymaps, but we can worry about that after we sort out specifics.

The remap entry (which prevents character insertion) still exists in the functional keymap, it's just filtered out from what users see.

I'm not sure I understand why this is true. This is modifying the actual keymap used by both display backends. Could meow--describe-keymap-format be a better place to put this?

Also, it seems that which-key filters this out which explains why I haven't seen this before. It's probably ok to let the legacy display function have some artifacts. When I was testing it out just now it's pretty apparent that there are many other display issues that make it look worse in subtle ways compared to which-key.

[Kaylebor]

To be fair I am not that familiar with the codebase, I mostly focused down on fixing a particular issue I was having and decided to open a PR once it was good; it's kind of accidental that this surfaced other issues too 😅

The specific issue I was having was that I was playing around with Meow and which-key, trying to ensure that +prefix values had proper names, and found that on the top level (and some nested levels) a <remap> -> +prefix entry kept popping up in keypad, but not really on which-key.
So digging a bit more (AI-assisted I must confess), I found this function; removing the [remap] value here did fix my issue, so I decided to open a PR and see if it's valuable for the main project or not.

While I am using this PR right now, and it appears to work, I am also just starting to get into meow (I come from Evil, which in my config manages to freeze Emacs, so here we are!). So there's probably a better approach to fix this, or there may be some way to configure which-key which avoids this issue altogether?
Or, can I maybe use keypad entirely instead? But if so, maybe keypad should be a separate package that meow depends on...

[eshrh]

Hmm, I was not able to reproduce getting a remap entry using which-key although I only tried halfheartedly. If you could explain how to reproduce it that might help.