Encrypting h(k) for defeating partition oracle attacks Is encrypting $h(k)$ (or even just $k$) and verifying it before checking the MAC enough to defeat partition oracle attacks and thus make the whole scheme robust/committing (without depending on properties of the cipher, unlike 0-padding)?
update 1:
basically $E_k(h(k)\mathbin\|m)$ or $E_k(k\mathbin\|m)$ where $E$ is an AEAD mode like $(x)chacha20poly1305$. The $k$ is derived from a password from a pkdf like argon2/scrypt/etc. At the start it is computed on both ends but then the party decrypting the ciphertext also checks if $h(k)$ (or just $k$) is correctly appended before the message.
The partition oracle attack works if the oracle returns information like the tag is correct or not. Without a response, there is no Oracle at all. The information can also be obtained from side-channels, too.
The partition oracle simply speeds up the password attack by grouping the passwords. The passwords are selected from a possible set of password list $\mathcal{D}$ and the corresponding key is generated by a PBKDF. The corresponding keys are grouped under a ciphertext that can be correctly decrypted.  Here one must note that the correctly decrypted ciphertext doesn't need to have some meaningful plaintext at all. The attacker only requires that under the grouped keys, the ciphertext has valid or invalid tag information returned back to them. This attack works since GCM and Poly1305 are non-committing, i.e. it is computationally feasible to find a pair of keys and a ciphertext (with its tag) that decrypts under both keys.
For the update 1

basically $E_k(h(k)\mathbin\|m)$ or $E_k(k\mathbin\|m)$ where $E$ is an AEAD mode like $(x)chacha20poly1305$. The $k$ is derived from a password from a pkdf like argon2/scrypt/etc. At the start it is computed on both ends but then the party decrypting the ciphertext also checks if $h(k)$ (or just $k$) is correctly appended before the message.

If one uses $E_k(h(k)\mathbin\|m)$ or $E_k(k\mathbin\|m)$, then two cases can occur;

The tag is not valid. This means that the oracle must return the $\texttt{tag invalid}$ response. Now, this is the core of the partition oracle attack. They sent the server a ciphertext that has a valid tag for the $k$ passwords. Returning invalid simply eliminates the $k$ passwords from the passible known password list $\mathcal{D}$.
If the communication is one-way, then there is no need to return any tag. But this really depends on the protocol. A usual protocol must respond.

The tag is valid. In this case, we return to your modifications. Now you will respond as the message format not valid. Viola, the partition oracle still get the information that the current tested $k$ password contains the valid password since the tag passed.


Of course, for both cases, there are false negatives for the attacker to eliminate. Those have a low probability to occur.
The main mitigation is using a committing AEAD that is not standardized yet or use HMAC with one key in as Encrypt-Then-HMAC. And remember using a strong password is always recommended.
For the update 2

The first block that also contains $k$ or $h(k)$ would be decrypted before checking the MAC tag (as an exception, unlike the following blocks). This is in order to verify whether the $k$ or $h(k)$ that is encrypted in the message matches the k that we are decrypting with before verifying the MAC tag (in order to not leak information about whether the MAC tag is invalid). If the encrypted k or $h(k)$ does not match the decryption k then the decryption aborts (before any MAC tag is checked at all)

I this case, I don't see any way that partition oracle attack will work. The attacker can still group but the probability of a random text to have the hash of the key is $1/2^{256}$ if SHA-256 is used. Therefore no feasible attack.
The standard online password attack will still work. Therefore the usual advice of having passwords with good strength is still applied.
I did not like the idea of encrypting the key under the same key, though we don't expect a problem with AES or ChaCha20. Someone can correct me if I'm wrong about this.