fix(D001, D002, D004, D005): distributed create/update/delete assertions

• D001_01_inc: the registration had no operations - the default federationOps does not include createEntity, so a broker must not forward the create (TS 104-175 clause 4.20 / 5.6.1). It now registers createEntity, and the test waits for the forwarded request before reading its body. The local query asks for the test's own entity (id + type): by type only it also returned the Vehicles other DistOps TCs leave behind.
• D002_02_01_inc / D002_02_02_inc: an inclusive Delete Entity where one source answers 404 is 204, not 207. ResourceNotFound is for "no entity held locally AND no matching registration" (TS 104-175 clause 10.2.8.4); a source not holding the entity is a wide registration's normal case.
• D002_02_exc: registered with redirectionOps, which includes deleteEntity (clause 9.2), so the no-forward premise never held. It now uses a new exclusive registration with operations ["retrieveOps"] for speed (context-source-registration-vehicle-speed-with-retrieve-ops.jsonld).
• D004_01_inc: the PATCH stub now sits at /entities/{id}/attrs/ (TS 104-176 clause 7.4.3, the URL the test's own stub count already checks); a fully successful distributed update is 204, not 207.
• D005_01_inc: the entity had no default instance of speed for the update fragment to change; it is now created from vehicle-speed-attribute.jsonld.

Tested - Against coraine, DistributedOperations (101 TCs): develop 60 pass / 41 fail. On this branch D002_02_01_inc, D002_02_02_inc, D002_02_exc, D004_01_inc, D005_01_inc pass, nothing else changed; D001_01_inc passes (run after the id + type query change, on its own and with D011_01_02/04).

🤖 Generated with Claude Code