[Tejasshack]

Summary

This PR brings 4.X onto master ahead of the October 15.

4.X is the Java 11 line. 4.0.0-RC2 adds the following wire-format changes:

• Vendor IDs 10000+. Vendor IDs above 8192 were dropped and never written into the encoded string. The vendor set now holds the full 16-bit range (1–65535), so an ID such as 10000 is encoded and returned on decode.
• Canada (TCF CA). Vendor ranges now use Fibonacci integer encoding, as required by the Canada spec. Strings that were encoded with the previous fixed-width ranges still decode (Fix TcfCaV1 (Canada) OptimizedRange encoding to use Fibonacci #106, Decode legacy fixed-range TcfCaV1 (Canada) strings (backwards compatibility) #107).
• Vendor and purpose bitfields. IDs are 1-based. Bit 0 was treated as ID 0, which shifted every later ID by one. Vendor and purpose bitfields, including ID 24, now round-trip on the correct bit (4.X: fix bitfield off-by-one encoding #108).
• TCF EU 2.3 segments. Optional segments are written when they contain data. isServiceSpecific no longer controls that, so vendorsDisclosed can be encoded when isServiceSpecific is true (4.X: US States with Subsections - MD, KY, RI, IN #109, issue TCF v2.3: Unable to encode additional segments (e.g., vendorsDisclosed) when isServiceSpecific=true #83).
• US state sections. Added Maryland (24), Indiana (25), Kentucky (26), and Rhode Island (27) (4.X: US States with Subsections - MD, KY, RI, IN #109).

Validation

• mvn -pl iabgpp-encoder test: 370 tests, 0 failures
• TCF EU round-trip covers vendor IDs 12 and 10000

[yuzawa-san]

is this workflow still used post beta if we have this in main, also it refers to the 4.X branch explicitly below and that branch will likely be going away.

[xdevanshux]

Yes we'll have to update the workflow accordingly. Once we are ready to move the 4.x branch to main, We will update the workflow in different commit

[aleksUIX]

I may be missing a check here, but this Canada string from master at a51d55f decoded VendorExpressConsent = [35] as [1131] on this head in my GppModel reproduction: DBABDA~BPSG_8APSG_8AAAAAAENAACAAAAAAAAAAABHABABGAAAAAA.YAAAAAAAAAA. It looks like the prefix round-trip check may accept a Fibonacci interpretation before trying the legacy fallback, which could change the reported vendor consent after an upgrade. Could we check this case and add a regression that preserves [35]?