Not following how you arrived at this. In the U2F, the server holds on to a copy of the key handle. Then during authentication, sends the key handle and challenge (referred to as "message" in this openssh doc) to the client.
But SSH is defined with the _Client_ picking how to authenticate first, so they can't do this.
There isn't a step in the SSH Authentication protocol where the server can say "Oh, here's the FIDO cookie you need". The SSH design says that (for public keys) the client starts by proposing "Hi, I can prove I know the private key that goes with this public key K1" and then the server either says "OK prove it" or "No, what else?". You can see this corresponds to the authorized_keys file on the server.
So instead you'll see the document calls this value "key_handle" and you'll see it is in the "private key" stored on the client, not with the "public key" stored on servers.
There's also a weird intermediary introduced that I think users may struggle to get their heads around. The FIDO cookie (this doc calls it a "handle" and the WebAuthn spec calls it the "Credential ID") is needed before a client can authenticate, and naturally you'd want to store this on a server, but in SSH the client chooses the authentication method to try not the server, so this cookie has to be stored on the client machine.
Say you enroll on your laptop. The laptop knows a cookie, the FIDO can take that cookie and prove it knows the private key, and that's enough to sign into the server. But without the FIDO key the laptop can't do anything, and without the laptop the FIDO key doesn't know which cookie is needed.
In effect it's two of the same factor. Something you have: The laptop and Something Else that you also have: The FIDO token.