On a follower, layered-table writes replay operations already confirmed by the leader, so every operation is expected to succeed. Any failure means replication has diverged from the leader - a state we can't recover from by returning an error code to the caller, since the caller (the apply path) has no meaningful way to handle it.

Explore treating any error on the follower's write path as a panic (WT_PANIC) instead of propagating it.

Expected benefits:

• Simplifies layered cursor code by eliminating error-code mapping and cleanup-after-error paths on the follower write path.
• Turns silent or hard-to-diagnose divergence into an immediate, loud failure at the point of first inconsistency.

The investigation should identify which errors on this path are genuinely expected in normal operation and must remain recoverable versus which indicate leader/follower divergence and should panic.

For example, WT_ROLLBACK under cache/eviction pressure is presumably legitimate even on a follower as may be prepare conflicts or EBUSY. So the likely outcome is not "panic on every error" but "panic on impossible errors, keep a short explicit list of expected ones" - which still allows removing most of the error-mapping and cleanup paths.