azcosmos: add ChangeFeedWithStartTimePostMerge capability bit (StartFrom timestamp fails after merge)

[kushagraThapar]

Summary

sdk/data/azcosmos/sdk_capabilities.go declares only supportedCapabilitiesPartitionMerge = 1 << 0. Java's HttpConstants.SDKSupportedCapabilities (lines 313-333) sends PARTITION_MERGE | CHANGE_FEED_WITH_START_TIME_POST_MERGE | IGNORE_UNKNOWN_RNTBD_TOKENS = 1+2+8 = 11.

Per the design-doc reference cosmosdb-design-docs/12-change-feed.md#partition-merge-startfrom-timestamp-scenarios-and-performance-concerns ("Critical Backend Finding" callout), the backend rejects change feed reads with If-Modified-Since on merged partitions when this capability bit is missing → 400 Bad Request: "IfModifiedSince is not currently supported with merged partitions."

Customer impact

Calling ContainerClient.GetChangeFeed with ChangeFeedOptions.StartFrom set against a container that has had merges will hard-400. The 410 retry loop introduced by #26768 won't catch a 400, so the failure is uncatchable below the public API.

Proposed fix

Add supportedCapabilitiesChangeFeedWithStartTimePostMerge = 1 << 1 (and supportedCapabilitiesIgnoreUnknownRntbdTokens = 1 << 3 for full Java parity) and OR them into the header value emitted by every request.

Context

• Surfaced during PR review of fix(azcosmos): GetChangeFeed split-resilient via overlap match, 410/Gone retry, multi-range continuation queue (#26767) #26768 (split-resilient change feed). Pre-existing gap; not introduced by that PR, but the new "split-resilient" framing makes the gap more customer-visible.
• Cross-SDK reference: Java sdk/cosmos/azure-cosmos/src/main/java/com/azure/cosmos/implementation/HttpConstants.java lines 313-334; RxDocumentClientImpl.java lines 2562-2568 (header populated on every request).

cc @tvaron3 @simorenoh