push: an expired retirement lets another device register a retired endpoint; fragment variants bypass the retirement check #2012

Found by the merge-pass gate while reviewing #1995 (head 6330812). Both behaviours predate #1995 and exist on main.

1. A retired endpoint loses its owner when the retirement mark expires.

When the push service answers 410, the server retires the endpoint for 30 days (server/push.ts). After that the mark is dropped, and any device that knows the endpoint URL, a watch-only one included, can register it with its own keys.

Reproduction over HTTP with a controlled clock:

1. The owner subscribes, the push service answers 410, and the endpoint is retired.
2. The watch device's DELETE then POST, and a POST after a restart, both get 410.
3. After 31 days, the watch device's POST with the original endpoint and its own keys gets 204.
4. The watch device now shows registered: true, and the former owner's status returns 404.

The practical impact is small. The push service already called that endpoint dead, so a push to it fails again with 410, and the owner's repair makes a new subscription. Still, the registration no longer belongs to the device that made it.

Expected: an expired retirement never hands the endpoint to a different device. Either keep the owning device id beyond the 30 days, or refuse registration of a once-retired endpoint by any other device.

2. A fragment variant gets past the retirement check.

E + "#attacker" is not matched against a retired E before expiry. The watch device's POST returns 204, and the owner's test push to it reaches the same retired push service, which answers 410. The watch device still can't send a test push itself (403).

Expected: normalise endpoints, for example by dropping the fragment, before comparing and storing them.