[Bug]: GenRadial replacement breaks vanilla parity

[jackusm]

Specifications
Rimworld version: 1.6
Combat Extended version: 16.7.1.0
Combat Extended source (Steam, GitHub, etc.): GitHub
Your operating system: macOS
Your mod list: (fill in full load order)

Description
From a modding perspective, CE’s Harmony_GenRadial replacement appears to diverge from vanilla GenRadial expectations.
In vanilla, mods can safely clamp using GenRadial.MaxRadialPatternRadius before calling radial methods. Under CE, the new effective cap is enforced by CE’s replacement logic (via MAX_RADIUS), and using vanilla-style clamping can still trigger CE’s “Not enough squares to get to radius...” error, which pauses gameplay. In practice, that means native API consumers will be penalised for following vanilla semantics due to the parity gap.
References:

• Vanilla GenRadial (decompile):
  https://github.com/josh-m/RW-Decompile/blob/d5bbfd741a46452bbfbec3a38b11a122f766f057/Verse/GenRadial.cs#L22
• CE replacement:
  

  CombatExtended/Source/CombatExtended/Harmony/Harmony_GenRadial.cs

  Line 17 in d9d64b6

  internal static class Harmony_GenRadial

Expected behavior
When replacing GenRadial, CE should preserve parity with vanilla semantics or at least avoid gameplay-pausing errors from using vanilla methods.

To reproduce
Not required; this is an API/behavior parity mismatch.

Complete the following checklist
I hereby verify that I have done the following:

• Confirmed that my game version and load order are correct.
• Confirmed that I am running the appropriate and most updated version of Combat Extended and required compatibility patches.
• Confirmed I am not running any mods with known incompatibilities with Combat Extended.
• Disabled Combat Extended and attempted to reproduce the behavior without success.