docs(serverless): add section Versioning and rollback in function and container limitations

Author: Bemilie

serverless/containers/reference-content/containers-limitations.mdx

@@ -86,3 +86,12 @@ For example, if you build an image using an ARM CPU, such as Apple Silicon M ser
 You must ensure that you build your image to target `amd64` architecture, to acheive this there are multiple solutions:
 * You can use the following Docker command: `docker buildx build --platform linux/amd64 .`, or
 * You can use an Instance with `amd64` architecture to run your builds.
+
+## Versioning and rollback
+
+Scaleway Containers do not currently support versioning or automatic rollback mechanisms.
+However, in the event of a failed deployment, the previously deployed version of the container will continue to handle
+incoming requests for up to 24 hours. After this period, the container in error will be deleted, and requests will no
+longer be served until a successful deployment is made. This ensures temporary service continuity, but it is important
+to monitor and resolve deployment issues promptly, as the fallback is not intended to provide long-term version control
+or rollback capabilities.

serverless/functions/reference-content/functions-limitations.mdx

@@ -55,3 +55,12 @@ To ensure the proper functioning of the product, we restrict the use of certain
   * **465**: Due to potential abuse (spam), no outbound traffic is allowed through this port, except from Scaleway Transactional Email SMTP servers.
 * Reserved environment variables:
   * `SCW_*`: Reserved for product configuration (for example: token validation).
+
+## Versioning and rollback
+
+Scaleway Functions do not currently support versioning or automatic rollback mechanisms.
+However, in the event of a failed deployment, the previously deployed version of the function will continue to handle
+incoming requests for up to 24 hours. After this period, the function in error will be deleted, and requests will no
+longer be served until a successful deployment is made. This ensures temporary service continuity, but it is important
+to monitor and resolve deployment issues promptly, as the fallback is not intended to provide long-term version control
+or rollback capabilities.