fix: prevent cross-parent IDOR via body-supplied up__ keys

[cschuerings]

Problem

finalizePrepareAttachment used a hasUpKey guard to skip parent-key population when any up__ key was already present in the request body. An attacker could exploit this by POSTing to a URL they are authorized for (their own parent) while supplying a different parent's ID in the body — the body value would be used as-is, associating the attachment with the victim's parent record.

Fix

Remove the hasUpKey guard entirely. Parent (up__) keys are now always derived from the URL path, overwriting any values supplied in the request body. A 404 is returned when the URL-referenced parent record does not exist.

Client-supplied attachment IDs on NEW are also rejected — the server always assigns a UUID.

Out of Scope

Authorisation checks beyond existence of the parent record (i.e. whether the requesting user is allowed to write to that parent) remain the responsibility of the application's service handlers.

[cschuerings]

Not exploitable without the fix. CAP's propagateForeignKeys already overwrites body-supplied up__ keys from the URL path before our handler runs. The removed hasUpKey guard was dead code; the new re-derivation is defense-in-depth only.