I'm attaching screenshots of the possibly relevant SecureCRT terminal emulation settings.

SecureCRT-TerminalSettings01.jpg (82,883 bytes)   

SecureCRT-TerminalSettings01.jpg (82,883 bytes)   

secureCRT-TerminalSettings02.jpg (76,137 bytes)   

secureCRT-TerminalSettings02.jpg (76,137 bytes)   

secureCRT-TerminalSettings03.jpg (78,821 bytes)   

secureCRT-TerminalSettings03.jpg (78,821 bytes)   

I tried to recreate the issue on my WSL2 install of Kali last night and I was not able to.
The numpad worked OOTB for the cmd.exe Kali zsh prompt, the Microsoft Terminal Kali zsh prompt, and the native Terminal on the kex Kali GUI.

I also tested on the first system again using the VMware remote console instead of SecureCRT over SSH. Even without the bindings present in the .zshrc file, the numpad keys work.

The only time I have problems is when I SSH into the VMware Kali linux system. I tried KiTTY and was able to reproduce the problem I had with SecureCRT.

I don't know why you're having this issue with the numpad, but it is working perfectly for me.

The keybindings that you are using are actually forcing the keys with the numlock enabled to behave as the numlock is disabled, which isn't correct.

For example, if you have the numlock enabled, if you press the key '7' your terminal receives the code '7', so there's no need for a keybinding for it. If you have the numlock disabled, pressing the key '7' sends the code '^[OH', which is already binded by bindkey -e and properly behaves like the Home key.
What you are actually doing there is forcing zsh to read '^[OH' like '7'

Maybe your issue is caused by the fact that you're SSHing to kali and the terminal you're using is not sending the codes properly