fix(#510): fix fragment parsing for padded hash values

[rbalogic]

Summary

Fix fragment parsing so ClearURLs preserves legal fragment payloads containing = padding, including cases like #token= and #token==.

This addresses the Claude login issue where magic-link URLs were being rewritten in a lossy way, causing the fragment token to break.

Problem

ClearURLs parses fragment content through URLHashParams, but the current implementation reconstructs fragment values incorrectly when they
contain trailing = or additional = characters.

Examples of broken cases before this change:

• #token= became #token
• #token== became #token
• #state=abc== became #state=abc

That behavior is not valid for arbitrary URI fragments and can break sites that store opaque state in the hash.

Changes

• parse fragment entries by splitting only on the first =
• preserve everything after the first = verbatim
• preserve empty fragment values instead of collapsing them
• update serialization so "" and null are handled distinctly

Result

The following fragments now round-trip correctly:

• #token=
• #token==
• #state=abc==
• #foo=bar=baz
• #plain

Scope

This PR is intentionally limited to the fragment-preservation bugfix.

The broader “disable on this site/domain” functionality will be handled separately as a feature PR.

Related Issues

• Implements Breaks Claude.AI login #510

[rbalogic]

@KevinRoebert could you take a look at this when you have time?

This PR is a narrow fix for fragment preservation. It addresses the Claude magic-link breakage by making sure hash payloads containing trailing = / == are not reconstructed in a lossy way.

The change is limited to URLHashParams and keeps the per-site disable feature discussion separate.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud