I'll assume by "majority/minority" you mean a network partition where at least half plus one nodes are still able to elect a leader, while the remainder are not.
In vanilla Raft, reads are appended to the Raft log like writes are. This means in order to commit a write, the client and the leader on the "majority" side will update the value as normal. The second client will either be unable to find a leader to contact at all, or if it is connected to an old leader, the leader will not be able to replicate the log entry necessary to service the read from the second client.
There are lease optimizations that rely on bounded clock error that allow for performing reads from the leader without appending entries to the log. Note this relies on the rate at which the clock advances, not the actual time.
There are also optimizations from Paxos research that would allow reading from the followers, but those also require contacting the leader at minimum.
In summary, Client One will succeed and Client Two will fail.
In vanilla Raft, reads are appended to the Raft log like writes are. This means in order to commit a write, the client and the leader on the "majority" side will update the value as normal. The second client will either be unable to find a leader to contact at all, or if it is connected to an old leader, the leader will not be able to replicate the log entry necessary to service the read from the second client.
There are lease optimizations that rely on bounded clock error that allow for performing reads from the leader without appending entries to the log. Note this relies on the rate at which the clock advances, not the actual time.
There are also optimizations from Paxos research that would allow reading from the followers, but those also require contacting the leader at minimum.
In summary, Client One will succeed and Client Two will fail.