To start with, there is one very big difference between traditional smartcards and FIDO/U2F tokens:
A smartcard relies completely on its internal storage – e.g. your Yubikey in its PIV mode has capacity for about ~20 certificate/key pairs (which could be used with SSH).
And while the certificates stored on a smartcard can of course be read out, private keys do not leave the smartcard in any shape or form.
FIDO/U2F tokens, on the other hand, have been designed to work with no internal storage whatsoever (the 'resident key' feature is an optional extra added much later).
When you enroll a U2F token with a website, the token generates a key and gives the website a "key handle" that contains all information necessary for it to reproduce the same key later – it can be either a unique seed for deterministic key generation (to be combined with the token's "master" seed), or it could even be the entire private key (of course, encrypted with the token's "master" key).
This way the U2F token has effectively infinite capacity without having any storage at all – it offloads the storage to the websites that it's used on.
(As a side note, that's also mostly how TPM2 chips function; they have a little bit of storage, but mostly they're designed to let the OS handle key storage.)
So to answer the bonus question first – no, there is most probably no way for a FIDO token to have non-downloadable resident keys, because the whole design of FIDO tokens is to have them downloadable; the entire "resident key" concept is practically just a convenience thing to let the key remember what usernames you've used on which sites.
(You could, of course, enable PIV mode in your Yubikey and start using it as a smartcard – OpenSSH can access it through PKCS#11.)
Regarding question 1, it's somewhat correct, although I'm not sure to what extent it's correct as the exact implementation could differ between FIDO tokens. For example, it could be the entire private key, but encrypted with yet another key that remains in the token; or it could be a seed for key generation, which would in a sense be like "half of private key".
In both cases, however, it's almost guaranteed to be an "all or nothing" kind of thing where knowing the "half" doesn't make it any easier to somehow crack the rest of the key.
And regarding question 2, the most likely answer is that each time you download the key, the token encrypts the "key handle" anew, with a new unique IV; and therefore the ciphertext is different even though the original data and the encryption key are still the same.
