fix: additional time to withdrawal delay (#326)

Make it clear that withdrawals won't come at 3
hours and there is extra time for executing
batches together

<!--

Thank you for contributing to the ZKsync Docs!

Before submitting the PR, please make sure you do the following:

- Update your PR title to follow [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/)
- Read the [Contributing
Guide](https://github.com/matter-labs/zksync-docs/blob/main/CONTRIBUTING.md).
- Understand our [Code of
Conduct](https://github.com/matter-labs/zksync-docs/blob/main/CODE_OF_CONDUCT.md)
- Please delete any unused parts of the template when submitting your PR

-->

# Description

Added language to match the Portal that shows 5+ hour withdrawal delay.
Explained that batches are aggregated which can add to the time.

## Linked Issues

<!-- If you have any issues this PR is related to, link them here. -->
<!--
Check out
https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
on how to automate linking a GitHub Issue to a PR.
-->

## Additional context

content/20.zksync-protocol/60.security/30.withdrawal-delay.md

@@ -16,7 +16,9 @@ with a time lock. The time lock across supported ZK chains has been reduced from
 hours](https://forum.zknation.io/t/zip-4-reduce-the-execution-delay-from-21-hours-to-3-hours/373).
 This change does not
 guarantee that batches will always be finalized on L1 within 3 hours, the actual
-finalization time depends on network activity and proof generation. Changing the
+finalization time depends on network activity and proof generation. Even for
+chains with high activity, there can be an additional 1 - 2 hours for batches
+to be aggregated and executed together to save on costs. Changing the
 delay further requires a governance proposal approved by the community.
 
 This design has the following advantages: