Provably fair card deck used by client and server

Say a server plays a game of blackjack with a client, and the cards are shuffled and dealt by the server. The shuffle itself may or may not be fair, but what needs to be shown is that the cards dealt weren't altered during the course of gameplay, ie: after the start of the hand, the cards in the deck do not secretly have their ordering changed by the server.

I was thinking of the following solution using cryptography and wanted to gain some feedback if it would be acceptable for a production system, and if not, why not:

Step 1) The server would secretly shuffle a deck of cards in some order, say the following (we omit the suit for simplicity): [3, 9, 2, ..., A]

It would then create the following message M:
M = "Card shuffle: [3, 9, 2, ..., A]. Random number: A96A...QT3"

Random number is a random number the server internally generates and keeps secret until the game concludes. Its length would be long enough to prevent the hash being cracked by the client via brute force (let's say it's 512 characters in length).

The server would now hash M using sha-256 or some other trusted hashing algorithm, eg: hash(M)

Step 2) Before the game begins, the server sends this hash(M) to the client, which the client stores. The client has no way of knowing M from what I can gather.

Step 3) The game begins, the cards are dealt in the shuffled order, the player makes decisions, and the game finally concludes.

Step 4) The client now wants to know that the game was fair, ie: the server didn't cheat by altering the cards during the hand. The server now sends the message "M" to the client in plaintext to show this.

Step 5) The client runs hash(M) and see's that it matches its hash(M) received in step 1.

Is this a fair way to prove the game was fair, without the client or server being able to cheat, excluding the possibility that the shuffle itself wasn't random? If the server were to alter the cards from the original shuffle during the course of the hand, then the client would see this in Step 5 (either the ordering would be transparently different to the client, or the hash of the message sent in Step 4 would be different to the one sent in step 2). Also, only a single hash is sent per hand, so the server can't generate a large number of hashes and send them separately then pick the best one during the course of the hand.

To extend knaccc's answer, it's even possible to use commitment schemes to prove (up to a point) that the server didn't cheat during the shuffle, e.g. like this:

1. The server chooses a random 128-bit number $x$ and a 128-bit blinding factor $r_x$, and sends the commitment $c_x = H(x \,||\, r_x)$ to the client.
2. The client chooses a random 128-bit number $y$ and sends it to the server. (No commitment is needed here.)
3. The server hashes $x$ and $y$ together to obtain a 128-bit seed $s = H(x \,||\, y)$.
4. The server uses $s$ as a seed to a deterministic PRNG, and uses the PRNG output to deterministically shuffle the deck.
5. The game is played with the shuffled deck.
6. At the end of the game, the server reveals $x$ and $r_x$, allowing the client to verify that the deck was shuffled correctly (and not modified after being shuffled).

Note that the server can still cheat, after a fashion, by inspecting the shuffled deck after step 4 and aborting the game (e.g. pretending that the connection was dropped) if it doesn't like the deck. A client should thus be suspicious of servers that frequently drop connections between steps 2 and 5, or even during the game in step 5. Ideally, there should be a way for a client to ask a server to resume an interrupted game at any point, and a client should be very suspicious of servers that refuse to do so.

(Securely implementing such a resume mechanism in a way that works even if the server crashes and forgets the game state seems doable, but probably outside the scope of this answer. Ask a new question if you're interested.)

Also note that the blinding value $r_x$ isn't actually needed here, since $x$ itself already has enough entropy to make brute-forcing the commitment infeasible. In fact it would arguably be slightly safer to omit $r_x$ and just make $x$ itself 256 instead of 128 bits long.

The bit lengths of $y$ and $s$ can also be increased if desired; 128 bits is just a safe and practical minimum. There's no point in making $s$ longer than the combined length of $x$ and $y$ together, though.