Fix max-width block save shape

[chubes4]

Summary

• Stop serializing dimensions.maxWidth as an inline wrapper declaration in php-transformer block save markup.
• Keep dimensions.maxWidth in block attrs, but align rendered markup with what WordPress core save() reproduces.
• Update block style support coverage for canonical save-shape parity.

Verification

• php php-transformer/tests/unit/block-style-support-conversion.php passes with 36 assertions.
• CV fixture verification with this transformer override reports 219/219 editor-valid blocks, 0 invalid blocks, editor_valid_block_rate 1.0.
• Coffee guard reports 214/214 editor-valid blocks, 0 invalid blocks, editor_valid_block_rate 1.0.
• Artist guard reports 126/126 editor-valid blocks, 0 invalid blocks, editor_valid_block_rate 1.0.

Notes

• This fixes editor-invalid evidence for the CV max-width save-shape regression.
• CV remains a browser-review candidate rather than solved because visual parity is still 2.80% against a 0.00% threshold.
• Coffee and Artist still show existing static-site-importer editor-open runtime failures from getCurrentPost being undefined; this PR does not address that separate recipe/runtime path.

AI assistance

• AI assistance: Yes
• Tool(s): openai/gpt-5.5 via OpenCode
• Used for: Compared scorecard artifacts, identified the generic save-shape mismatch, implemented the patch, and ran focused verification.

[chubes4]

Closing as superseded by #565.

I compared this branch against current trunk after #564/#565/#568. The remaining #567 delta is the max-width save-shape behavior, but #565 already fixed the invalid core wrapper serialization by omitting unsupported dimensions.maxWidth attrs for native wrappers and added coverage for both group and columns wrappers. Rebasing #567 as-is would partially reverse that #565 contract by expecting dimensions.maxWidth to remain in attrs while only suppressing the inline wrapper declaration.

No unique PHP-transformer change remains that should land separately from #565.