Accept a volume transfer offer into this project

Called in the RECEIVING project's scope with the transferId and authKey the donor was given. On success the volume belongs to this project: the provider reassigns it, this API's inventory row follows, and billing follows with it. The tenant boundary is enforced here, not by the key. The provider would honour a key presented from anywhere in the cloud; this route refuses a transfer whose source volume does not sit under the SAME tenant as the accepting scope, and refuses it as 404 NOT_FOUND rather than 403 so an offer from another tenant is indistinguishable from one that does not exist. Billing. The hour bucket containing the acceptance belongs in full to the SOURCE subscription; the first bucket starting at or after it is the destination's. That is the same cut-over fixed for project moves, applied to one volume, and it is why usage is sealed against the source in the same transaction that flips the owner. No hour is split, duplicated or dropped. Validation: unknown or already-accepted transferId, a wrong authKey, and an offer from another tenant are ALL 404 NOT_FOUND — distinguishing them would let a caller probe for offers they cannot see. The receiving subscription's q-volumes / q-gigabytes quota must cover the volume (→ 409 QUOTA_EXCEEDED): accepting is the one way a project gains a volume without passing the create gate. Caller needs owner|admin|contributor on the receiving scope. Async & state: Asynchronous — 202 with an Operation. On completion the volume appears in this project's inventory and a resource.updated SSE frame (kind storage.volume) is emitted in the receiving scope. Errors: 401; 403; 404 unknown scope, unknown/spent offer, wrong key, or cross-tenant offer; 409 QUOTA_EXCEEDED; 422 malformed body; 500 provider failure. Idempotency/Concurrency: Idempotency-Key is optional (recommended); the replay returns the original 202. The offer itself is single-use at the provider, so two racing accepts cannot both win.