Test the fbc/fbp parsing against Meta's own parameter builder

[loevgaard]

Summary

The bug behind #13 was drift: our regexes no longer matched what Meta writes into _fbc and _fbp. Meta's own facebook/capi-param-builder-php is the best machine-checkable statement of that format, so this PR adds it as a dev dependency and uses it as a test oracle. It is never used in src/, so it adds nothing at runtime.

The invariant

Everything the builder writes, Fbc/Fbp parse and write back byte for byte.

It is deliberately one-directional rather than "the same parsing". The builder's own parser is private and only structural; it accepts a.b.c.d as a valid cookie, so matching it would mean loosening the value objects. There is also one place where we are more lenient on purpose: as a two-character appendix the builder only accepts six language tokens, while the value objects accept any 2 to 8 characters, because that list can grow.

ParamBuilderConformanceTest runs processRequest() and feeds the results to fromString():

• a new fbc built from an fbclid, including base64url click ids with - and _, asserting click id, subdomain index, creation time and appendix
• an fbc the builder replaces when the fbclid changes
• a generated fbp, 20 rounds per host because the random number varies in length
• legacy four-segment cookies the builder upgrades with an appendix, asserting every component survives
• cookies it passes through unchanged: all three eight-character appendix kinds and the six legacy language tokens
• hosts that yield different subdomain indexes: a registrable domain, a subdomain, a host with a port, a two-label public suffix with a domain list, a deep host, localhost and an IP address

The oracle found a bug straight away

For a deep host such as a.b.example.co.uk the builder writes fb.3.…, and the value objects only accepted a subdomain index of 0, 1 or 2, so they rejected a cookie Meta's own code produces. The index is the number of dots in the cookie domain; 0 to 2 are merely the examples Meta documents.

Fixed in this PR, since shipping the tests with a hole cut around the case would defeat their purpose:

• Fbc::fromString() / Fbp::fromString() accept 0|[1-9]\d{0,2}: any index up to three digits, without a leading zero, so the value still round-trips byte for byte.
• Fb::withSubdomainIndex() accepts any non-negative integer. The three SUBDOMAIN_INDEX_* constants stay, with a docblock explaining they are examples.

This only relaxes validation, so it is not a BC break (Roave: none).

Dependabot

facebook/capi-param-builder-php is added to the allow list in .github/dependabot.yml. That covers a new major, where Dependabot widens the constraint and CI runs the conformance tests against it.

A release inside ^1.3.1 produces no Dependabot PR, because no composer.lock is committed. The highest jobs install it the next time CI runs, so a format change in a minor release is noticed at the next push or PR. An earlier revision of this PR added a weekly scheduled run to shorten that; it was dropped in review.

Limits

Passing these tests proves agreement with Meta's PHP builder, not with the browser pixel script that writes most cookies in the wild.

Test plan

• 163 tests, 100 % line coverage; PHPStan (level max), ECS, dependency analyser, composer normalize green; Infection MSI 95 % / covered 95 %, no new escaped mutants
• New unit tests for the subdomain index: accepted above two, rejected with a leading zero, negative, four digits or non-numeric
• lowest on PHP 8.1: php-business-sdk 25.0.0 next to the builder 1.3.1, PHPUnit and PHPStan green
• Both YAML files parse; Roave BC check locally: no breaks
• After merge: Dependabot lists both packages