Reduce the blast radius when exception thrown in ApplySnapshot / IngestSST

Enhancement

Consider just let the related region not be able to read instead of panic the TiFlash process when meets unexpected behavior like https://github.com/pingcap/tiflash/issues/10147

After a RaftLog is received on the tiflash-proxy, but fails to apply to TiFlash storage. There is no mechanism to "rollback" or "throw away" the RaftLog (so does it for TiKV AFAIK). Now when exception detected when applying RaftLog or Raft snapshots, TiFlash always panic, causing TiFlash downtime.
In order to control the blast radius, we have to address these problems:

1. TiFlash need to confirm whether each check fails impact scope, whether it only affect the current Region, or table, or the TiFlash node, or even the whole cluster.
   1. This requires carefully discussion over each check on the RaftLog/Raft Snapshot handling routine
   2. Also it require to check the DDL routine on TiFlash, because decoding RaftLog/Raft Snapshot will trigger DDL syncing
2. How to handle the following reading / writing request after the abnormality happen?
   1. Can we reject the following writing to Region/Table/TiFlash node without great impact to the cluster?
   2. Alternatively, can TiFlash reject the raft-log in a more pre-checking stage? Like rejecting the raft-log message with invalid key-range from TiKV?
   3. Can we reject the following reading request to Region/Table/TiFlash node without great impact to the cluster?

Start by tracing the ApplySnapshot and IngestSST paths, then review the RaftLog/Raft Snapshot handling and DDL syncing mentioned in the issue. Document which failures affect a Region, table, node, or cluster, and define the read/write behavior and pre-checking needed for each scope. Done means the blast radius and abnormal-request handling are specified clearly enough to implement.