Normalize absolute TTL expiry semantics for partial update

Context

PR #105 adds portable shallow partial update through MulticloudDbClient.update(). During review, the proposed provider-specific TTL-preservation capability was removed because support by only one provider does not establish a useful portable contract.

Current behavior differs across the two participating providers:

• DynamoDB UpdateItem leaves the existing absolute ttlExpiry value unchanged.
• Cosmos DB patchItem advances _ts, restarting a relative TTL countdown.

TTL timing is therefore explicitly outside the portable partial-update contract for now. Callers requiring a fixed absolute expiry must not use update() on TTL-bearing items.

Goal

Define and implement one portable absolute-expiry behavior across Cosmos DB and DynamoDB without silent provider divergence.

Design questions

• Can expiry preservation remain one native write with no pre-read or read/merge?
• Is SDK-owned absolute-expiry metadata required?
• How should ETag/concurrency races, RU/request cost, retries, and timeout ambiguity be handled?
• How should existing provider-native TTL fields and already-stored items migrate?

Acceptance criteria

• Cosmos DB and DynamoDB expose the same documented result for a partial update on a TTL-bearing item.
• Any unsupported case is rejected before provider I/O with a normalized error rather than silently diverging.
• Conformance coverage verifies absolute expiry before and after update on every participating provider.
• Capability declarations, API/SPI Javadocs, compatibility documentation, and cost implications are aligned.
• The chosen design documents whether the operation still performs one write with no pre-read.

Related: #105

Start by reading PR #105 and the MulticloudDbClient.update() contract, then compare the DynamoDB UpdateItem and Cosmos DB patchItem behavior described here. Resolve the design questions before changing the provider implementations. Done means both providers document and enforce the same TTL result, unsupported cases fail before provider I/O, conformance coverage verifies expiry, and capability, API/SPI, compatibility, and cost documentation agree.