Dimension padding behaves differently when set to the default value vs omitting

With the fix of MC-272062, the dimension_padding option in jigsaw structures behaves differently when set to 0 vs omitting the field. The 24w19a change-log specifies that dimension_padding is an optional field with a default value of 0.

How to reproduce:

1. Create a new world with the attached datapack
   • This datapack adds 2 structures, test:red and test:blue.
   • Both structures are projected to the OCEAN_FLOOR_WG heightmap and are set to generate in all end biomes
   • test:red has "dimension_padding": 0 set
   • test:blue doesn't specify a dimension_padding field
2. Teleport to the end: /execute in minecraft:the_end run tp @s 2000 100 0
3. Look around:
   • On end islands both red and blue structures generate
   • In areas with no end islands, only the blue structures generate

Expected Result:
I'd expect the structures to behave identically because the only difference is adding a field and setting it to the default value.

Code analysis:

This bug happens in the check for the start piece.
net.minecraft.world.level.levelgen.structure.pools.JigsawPlacement.isStartTooCloseToWorldHeightLimits:

if (dimensionPadding == DimensionPadding.ZERO) {
    return false;
} else {
    \\...

This disables dimension padding only when the pre-defined ZERO dimension padding object is used.

• When the field isn't specified the ZERO is used as the default
• When manually specifying 0 a new object with 0 padding is used, failing the check

A fix would be replacing the == with a .equals call.

Note:

In case this different behavior for omitting the field is intended, I would like to point out:

• The dimension padding is always active for all jigsaw pieces other than the start piece.
• The .optionalFieldOf CODEC method uses .equals when comparing a value with the default during encoding. This means that the data generator can never produce the dimension_padding field with the value of 0, since it would be omitted in this case. In other words: The encoding -> decoding possibly changes the behavior of the dimension padding when set to 0.