Add universal dyed catwalk railings

[viralhysteria]

Summary

Catwalk stairs currently support attaching a railing to their left/right side, but the attached railing's texture was hard-tied to a single state shared by both sides — meaning a railing could only ever be textured as whatever metal or color happened to occupy that one shared property, and mixing metals/colors on the same stair, or applying a universal dyed railing to a stair of a different metal, wasn't representable in the block state at all.

This PR splits railing color into independent per-side state, introduces a proper RailingColor type that distinguishes "this side's own metal" from "a universal dye," and updates the data-driven texture wiring (blockstates + models) so any combination of metal stair + dyed or standard railing renders correctly. No existing metal-only railing behavior changes — a stair with only standard railings placed behaves exactly as it did before this PR, both visually and in terms of block state defaults.

Changes

RailingColor (new)
A 7-value enum: 7 of the 16 vanilla DyeColors, plus a NATURAL sentinel meaning "no dye — use this stair's own metal-matched rail texture." This is intentionally its own type rather than reusing DyeColor directly, since DyeColor has no way to express "undyed." fromRegistryPrefix(String) resolves a placed railing item's registry name back into the correct RailingColor, falling back to NATURAL for anything that isn't a recognized universal dye.

BlockRegistry

• Implemented a new DYED_CATWALK_RAILINGS HashMap to map each dyed variant as a modifier of Andedsite catwalks

Catwalks

• Added a recipeDyeRailing method for allowing shapeless crafting of dyed railings by pairing a single dye with an Andesite railing

CatwalkBlock

• Added isPathFindable override to fix mob pathfinding

CatwalkStairBlock

• Implement two new independent properties, RAILING_LEFT_COLOR and RAILING_RIGHT_COLOR, each defaulting to RailingColor.NATURAL.
• onSneakWrenched now reads the removed side's own color property and returns the matching item — a metal-matched standard railing when that side was NATURAL, or the correct dyed railing item when it wasn't — instead of always assuming the stair's base metal.
• Everything else (shape lookup, waterlogging, rotation, placement) is unchanged.

RailingBlockItem

• useOn now gates whether a railing is allowed to attach to a stair at all, rather than always attaching and only varying the resulting texture.
• Placement/orientation/duplicate-side checks are unchanged.
  • the item is a dye (universal — attaches to a stair of any metal), or
  • the item is a metal railing whose metal matches the stair's own metal.
• Added resolveMaterialKey, which determines which BlockRegistry.CATWALK_RAILINGS entry (a metal name like "Iron", or a dye name like "Blue") the clicked item's registry path corresponds to.
• isMetal is derived by checking whether the resolved key exists in ItemRegistry.METAL_TYPES — the same map ItemRegistry itself uses to define what a "metal" is, so there's no separate metal enumeration to keep in sync.

Assets (blockstates + models)

• Per-color overlay models (<color>_catwalk_stairs_rail_left/right.json) replace per-metal-only overlay models for dyed cases, parented off the existing shared rail geometry so no new geometry was authored.
• Each metal's blockstate multipart entries were extended with railing_left_color/railing_right_color conditions: a natural case (pointing at that metal's existing, unmodified _rail_left/_rail_right model) plus one case per registered dye color.
• The base, unconditional <metal>_catwalk_stairs.json model (stair body + fixed corner-post texture) is untouched in behavior — it still always renders with that metal's own native texture, since it isn't state-conditional. Only the attachable railing overlay is dyeable per instance.

Why existing metal variants are unaffected

• Default state is NATURAL on both sides. Any stair placed or already in the world with no railing color explicitly set behaves exactly as before — same texture, same lookup path (<metal>_catwalk_stairs_rail_left/right), same recipe/wrench return.
• The natural blockstate branch is structurally identical to the original. For each metal, the regenerated blockstate's natural-conditioned entries are a 1:1 match to the pre-existing railing_left/railing_right entries, just with an added railing_left_color: natural / railing_right_color: natural condition — same model reference, same y rotation per facing.
• No shared textures were touched. Dyed rendering is handled entirely through new, additive model files; no existing per-metal model or texture file was repointed at a dye color as part of this change.
• Wrenching preserves correctness per side. Because color is now read from the side actually being removed rather than inferred from the stair's base metal, standard railings on modified stairs still return the correct standard item, and this also fixes a latent case where a stair with a dyed railing on one side would previously have handed back the wrong item on wrench.

Known limitation / follow-up

The stair's baked-in corner-post nub (part of the always-applied base model, not the removable railing) still always renders in the stair's native metal color, even when a dyed railing is attached next to it. Making the nub match the attached side's dye would require splitting that geometry out per side and adding its own state-conditioned multipart entries — left as a possible follow-up rather than bundled into this PR, since it's a larger structural change and not required for the core feature. I also chose to limit the initial selection of variants due to the nature of how the initial implementation relies on expanding blockstate json files based on which colors seemed most applicable to real world examples of guard rails for worksafe safety compliance.

Testing

• Placed standard railings on every registered metal's stairs — visual output unchanged from pre-PR behavior.
• Placed each registered dye color's railing on stairs of multiple different metals, independently on left/right sides, confirmed correct texture per side as well as stability with Sable physics assemblies
• Wrenched off railings in mixed configurations (metal-A stair + dyed-left + standard-right) and confirmed correct item returned per side.
• Clean runData / build pass with no registry or asset-loading errors.