Improve partition key indexing guidance in index-policy.md

- Clarify that partition keys don't require indexing to function
- Explain performance impact of unindexed partition keys on cross-partition queries
- Add specific guidance for hierarchical partition key indexing
- Emphasize the need to include individual levels of HPK hierarchy for optimal performance

Author: HansWieser-MS

articles/cosmos-db/index-policy.md

@@ -45,8 +45,8 @@ In Azure Cosmos DB, the total consumed storage is the combination of both the Da
 * When data is deleted, indexes are compacted on a near continuous basis. However, for small data deletions, you might not immediately observe a decrease in index size.
 * The Index size can temporarily grow when physical partitions split. The index space is released after the partition split is completed.
 
-> [!NOTE]
->  - The partition key (unless it is also "/id") is not indexed and should be included in the index.
+> [!IMPORTANT]
+>  - The partition key (unless it is also "/id") is not indexed and should be included in the index. Partition keys do not require indexing to function, but if you do not include them in your indexing policy, any queries filtering on partition key hierarchy will force full scans that become cross-partition queries, resulting in higher RU consumption. In the case of hierarchical partition keys, you want to include the individual levels of the partition key hierarchy in your indexing policy to ensure efficient query performance.
 - The system properties id and _ts will always be indexed when the cosmos account indexing mode is Consistent
 - The system properties id and _ts are not included in the container policy’s indexed paths description. This is by design because these system properties are indexed by default and this behavior cannot be disabled.