Changes after review

docs/technical-documentation/restoring_lost_data.md

@@ -3,6 +3,10 @@
 If you've ever accidentally deleted important data either by using Terraform or by hand, there's still hope to recover the data.
 By using the Snowflake's Time-Travel feature, you can restore lost data and undo those accidental deletions.
 
+> Note: Currently, the recovery process is predominantly manual, relying on SQL commands and the Terraform CLI. 
+We made a strategic decision not to integrate it as a provider feature at this time, as demand for this functionality was not significant.
+Following the release of V1, we intend to reassess the topic of data recovery and UNDROP functionality to explore potential integration into the provider, evaluating its necessity and feasibility.
+
 You should be prepared beforehand by specifying how much of the historical data Snowflake should keep by setting the [DATA_RETENTION_TIME_IN_DAYS](https://docs.snowflake.com/en/sql-reference/parameters#data-retention-time-in-days) parameter.
 When using our provider, you can set this by using one of our parameter-setting resources (like [snowflake_account_parameter](https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/account_parameter) or [snowflake_object_parameter](https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/object_parameter))
 or set it on the resource level (e.g. `data_retention_time_in_days` in [snowflake_database](https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/database)).

v1-preparations/CHANGES_BEFORE_V1.md

@@ -5,10 +5,16 @@ Each provider version lists changes made in resources and datasources definition
 
 ## Default values
 For any resource that went through the rework as part of the [resource preparation for V1](https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#preparing-essential-ga-objects-for-the-provider-v1),
-the behaviour for default values may change from the previous one. Now, whenever the value is not specified in the configuration,
-we let the Snowflake fill out the default value for a given field (if there is one). Using such defaults may lead to non-idempotent cases where the same configuration may 
-create a resource with slightly different configuration in Snowflake (depending on the Snowflake Edition and Version, current account configuration, and most-likely other factors). 
-That is why we recommend setting optional fields where you want to ensure that the specified value has been set on the Snowflake side.
+the behaviour for default values may change from the previous one. 
+
+In the past, the provider copied defaults from Snowflake, creating a tight coupling between them. 
+However, this approach posed a challenge as the defaults on the Snowflake side could change and vary between accounts based on their configurations.
+
+Now, whenever the value is not specified in the configuration, we let the Snowflake fill out the default value for a given field
+(if there is one). Using such defaults may lead to non-idempotent cases where the same configuration may 
+create a resource with slightly different configuration in Snowflake (depending on the Snowflake Edition and Version, 
+current account configuration, and most-likely other factors). That is why we recommend setting optional fields where
+you want to ensure that the specified value has been set on the Snowflake side.
 
 ## v0.91.0 ➞ v0.92.0
 ### snowflake_scim_integration resource changes