PDP: Implement pdpv0 client termination endpoint

[rvagg]

Replaces #1028

Ref: https://www.notion.so/filecoindev/Data-Set-Terminations-Clean-up-360dc41950c1801ebf0aff017a322e7f

Curio currently has a data set delete route stub in pdp/handlers.go, but this should become client-requested termination, not direct deletion. Deletion is an internal Curio/PDP cleanup operation after service termination and payment finalisation.

Scope:

• Add a client-facing terminate endpoint for pdpv0 data sets, POST /pdp/data-sets/{id}/terminate.
• Implement/replace the existing handler stub path in pdp/handlers.go (currently handleDeleteDataSet).
• Verify the data set exists and belongs to the requesting service.
• Require non-empty extraData for client-requested termination.
• No needt to validate EIP-712 in Curio. Pass extraData through unchanged; FWSS/PDPVerifier remains authoritative for verifying the client signature.
• Empty extraData should remain an internal/provider termination path only, not accepted as a successful client termination request.
• Submit the FWSS termination transaction via the existing pdpv0 termination path and return the transaction hash, matching other PDP endpoints that submit transactions.
• Return 201 Created/similar with a Location header carrying the tx hash, matching create/addPieces style.
• Add a termination status endpoint, e.g. GET /pdp/data-sets/{id}/terminated/{txHash}.
• The status endpoint should report tx status/success, whether FWSS termination has been confirmed, and the service termination epoch when known.
• Make repeated calls idempotent while termination is already pending or complete.

[LexLuthr]

@rvagg I need a clarification - do we respond to GET /pdp/data-sets/{id}/terminated/{txHash} in perpetuity or just while we are handling the termination and deletion. Perpetuity means, one more table keeping track of this since we clean up deleted dataSet from their table.

[rvagg]

@LexLuthr no, this is only going to be needed fairly briefly. In fact it's possible that we don't even ask for that URL and just read txHash ourselves. I don't recall exactly how we do it today but original Synapse coded addPieces etc. as a dual-check -- what do we (client) see as the chain saying about that tx, and what does the server say about that tx, since server has a task system delay and its own confirmations setting and we have a different set of constraints, when they both agree then we're good to go. We may do the same in this instance, but no more than that - once we've got the 👍 then we don't care anymore. So that's a fairly short window for Curio needing to respond to this.