sharing: DELETE /sharing/rules/:idOrName answers 500 for both address forms — rules cannot be deleted over REST

[baozhoutao]

Found while verifying the 17.0.0-rc.1 checklist on #3909 (F2). Verified on main @ 1ee48bc60, showcase under os serve --dev.

DELETE /api/v1/sharing/rules/:idOrName — the route the REST ledger documents as the SDK's shares.rules.delete — fails unconditionally:

DELETE /api/v1/sharing/rules/rc1_rule_livetest
→ HTTP 500 {"code":"RULE_DELETE_FAILED","error":"Delete requires an ID or options.multi=true"}

DELETE /api/v1/sharing/rules/srule_05574dc1-d342-… (the rule's real id)
→ HTTP 500 {"code":"RULE_DELETE_FAILED","error":"Delete requires an ID or options.multi=true"}

Both address forms the route advertises (:idOrName) hit the same wall — the handler's engine delete call passes neither an id filter the driver accepts nor options.multi, so no sharing rule can be deleted over REST at all. The 500 also leaks the driver's internal wording instead of a catalogued error (ADR-0112).

Consequence compounds with the deactivation gap (filed separately): a materialized rule grant cannot be withdrawn by deactivating the rule, and the rule cannot be deleted either — an over-granted rule is unrecoverable from the API surface.

Expected: DELETE resolves :idOrName to the stored row (as GET on the same route already does — GET /sharing/rules/rc1_rule_livetest works), deletes it, withdraws its materialized grants, and failure modes speak catalogued codes.

Part of the #3909 rc.1 verification (section F2).

[baozhoutao]

Tracked under the v17 verification tracker #3909 (section F, rc.1 run 1).

[baozhoutao]

Rolled up in #4482 (all 17 defects from the v17 verification, grouped by severity with a suggested RC-exit triage).