I confirmed your suggested steps DO produce the problem.

Specifically:  From a terminal enter:  emacs -Q

In the *scratch* buffer that presents paste

(global-set-key [f3] 'nonincremental-repeat-search-forward)
(custom-set-variables '(which-key-mode t))

C-x C-e the lines in presented order.
C-h k f3 quickly and see nonincremental-repeat-search-forward
C-h and wait for the menu before typing k f3  
kmacro-start-macro-or-insert-counter is now in the *Help* buffer.

Date: Sun, 25 May 2025 18:19:20 -0500
From: Rick <rbielaws@gmail.com>
Cc: 78582@debbugs.gnu.org

1) I didn't realize I never used -q.  I edited the wrong .desktop file.  Using -q
    prevents the two statements that set up the problem from executing.  You CAN
    specify --no-site-file but -q or -Q destroy the setup conditions and --debug-init 
    often prevents the problem from occurring too so don't do that either.

Sorry, I'm not following.  First, what does the .desktop file have to
do with it?  If it's involved, please explain why; otherwise, let's
not consider unnecessary complications: this issue is complicated even
without that.  AFAIU your recipe, Emacs should not try to load any
.desktop files in this case.

Second, I did try your recipe without -q and without -Q, by using a
.emacs file with those two lines and nothing else.  I couldn't
reproduce the problem.  I asked (among other things) whether you are
able to reproduce by starting "emacs -Q" and then evaluating those
two lines in such a session.  AFAIU, this should be equivalent to your
recipe, and if it turns out it isn't equivalent, we need to consider
what happens during startup.

2) I used 'nonincremental-search-forward rather than 'describe-key as the example 
    function assigned to F3 when I developed the example.  I have no idea why using
    'describe-key makes a difference.  In fact, if I use it, the menu of possible prefix
    completions never shows up.  Just the mini-buffer prompt with ? if I want help.
    Hard to say if this isn't a completely different problem or perhaps related.
In any case it seems saver to use 'nonincremental-search-forward .

Please show a full recipe using nonincremental-search-forward, and I
will try it.

As I think about the strangeness of the symptoms I can't help but think it's 
related to how the build loads into memory and something is assuming some
block containing definitions has never loaded when, it not only has been, but 
it has even been modified.  So the load is really a reload that's revering things. 
Afterward, it knows it's been loaded and never overwrites that data again.
It's the only thing I can think of that explains why I've never caught it 
overwriting the same keys multiple times.

I wouldn't go to such lengths without a good reason.  We don't yet
have a reason to assume something this weird happens.

Thanks.