Quartz, red sandstone and cut red sandstone slabs have a blast resistance of 0.8 instead of 6.0

The bug

In 26.2, quartz_slab, red_sandstone_slab and cut_red_sandstone_slab all had a blast
resistance of 6.0, like every other stone-type slab. Since 26.3 Snapshot 1 all three have a
blast resistance of 0.8, so they are destroyed by explosions that used to leave them intact.

sandstone_slab and cut_sandstone_slab — the direct counterparts of red_sandstone_slab and
cut_red_sandstone_slab — still have 6.0, so the sandstone family is now internally
inconsistent: a red sandstone slab is destroyed where the identical sandstone slab survives.

Measured values (hardness / blast resistance):

block 26.2 26.3 Snapshot 1-6
quartz_slab 2.0 / 6.0 2.0 / 0.8
red_sandstone_slab 2.0 / 6.0 2.0 / 0.8
cut_red_sandstone_slab 2.0 / 6.0 2.0 / 0.8
sandstone_slab 2.0 / 6.0 2.0 / 6.0 (unchanged)
cut_sandstone_slab 2.0 / 6.0 2.0 / 6.0 (unchanged)
stone_slab 2.0 / 6.0 2.0 / 6.0 (unchanged)
smooth_quartz_slab 2.0 / 6.0 2.0 / 6.0 (unchanged)

Hardness is unaffected; only blast resistance changed. These three are the only blocks in the
entire block registry whose properties changed between 26.2 and 26.3 Snapshot 6.

Steps to Reproduce

1. Create a Creative superflat world in 26.3 Snapshot 6.

2. Place a flat 5x5 platform of red_sandstone_slab, and next to it a flat 5x5 platform of
   sandstone_slab.

3. Stand back and let a ghast fire a fireball at each platform (or summon the fireball).
   A ghast fireball has explosion power 1.

4. Compare the two platforms.

Observed Results

The red sandstone slabs are destroyed. The sandstone slabs are untouched.
The same test in 26.2 leaves both platforms untouched.

Expected Results

Both platforms behave the same, as they did in 26.2 and as sandstone_slab still does.

Why this looks unintentional

Blocks.java in 26.2 declared all five slabs with an explicit strength(2.0F, 6.0F). In 26.3
these declarations were compacted into a registerSlab(...) helper that has two relevant
overloads: a 3-argument form that inherits the base block's blast resistance, and a
4-argument form that sets it explicitly.

SANDSTONE_SLAB = registerSlab(..., SANDSTONE, 2.0F, 6.0F); // kept 6.0
CUT_SANDSTONE_SLAB = registerSlab(..., CUT_SANDSTONE, 2.0F, 6.0F); // kept 6.0
QUARTZ_SLAB = registerSlab(..., QUARTZ_BLOCK, 2.0F); // now 0.8
RED_SANDSTONE_SLAB = registerSlab(..., RED_SANDSTONE, 2.0F); // now 0.8
CUT_RED_SANDSTONE_SLAB = registerSlab(..., CUT_RED_SANDSTONE, 2.0F); // now 0.8

SANDSTONE, CUT_SANDSTONE, QUARTZ_BLOCK, RED_SANDSTONE and CUT_RED_SANDSTONE all have a blast
resistance of 0.8, so the 3-argument form silently drops the 6.0. The two sandstone slabs use
the 4-argument overload on adjacent lines and keep 6.0, which is what makes this look like an
oversight rather than a deliberate rebalance: if the intent had been to make slabs inherit
from their base block, sandstone_slab would have been changed too.

For reference, the explosion cost of a block is (blast_resistance + 0.3) * 0.3, subtracted
from a ray budget of power * (0.7 + random * 0.6). At resistance 6.0 the cost is 1.89, above
the 1.3 maximum budget of a power-1 explosion, so such an explosion can never break it. At
0.8 the cost is 0.33.

Related

MC-53641 (Reopened) and its duplicate MC-280447 argue the opposite direction — that the
slabs' 6.0 is itself the long-standing anomaly and should match the base block. This report
is not asking to revert that; it is pointing out that whichever value is correct, the five
sandstone/quartz slabs should agree with each other, and right now three were changed while
their direct counterparts were explicitly left behind.