refactor(strftime): rely on memoryLimit for width control

Remove MAX_STRFTIME_PAD hard capping and rely on memoryLimit enforcement before padding allocation. Update strftime/date tests and security-model docs to match the new boundary and renderLimit caveats.

Co-authored-by: Cursor <[email protected]>

docs/source/tutorials/security-model.md

@@ -38,7 +38,7 @@ Restricting template size alone is insufficient because dynamic loops with large
 
 Render time is checked on a per-template basis (before rendering each template). In the above example, there are 2 templates in the loop: `order: ` and `{{i}}`, render time will be checked 10000000x2 times.
 
-For time-consuming tags and filters within a single template, the process can still hang.
+`renderLimit` is not a hard CPU limiter. It is checked between template renders, so compute-intensive filters/tags/user-defined functions or deeply nested template execution between checks can still cause DoS.
 
 ### memoryLimit
 

docs/source/zh-cn/tutorials/security-model.md

@@ -38,7 +38,7 @@ LiquidJS 提供了面向 DoS 的限制选项（`parseLimit`、`renderLimit`、`m
 
 渲染时间是在渲染每个模板之前检查的。在上面的例子中，循环中有两个模板：`order: ` 和 `{{i}}`，因此会检查 2x10000000 次。
 
-单个模板内的标签和过滤器仍然可能把进程挂起。
+`renderLimit` 不是硬性的 CPU 限制器。它是在模板渲染边界做检查，因此检查点之间的高计算开销过滤器/标签/用户自定义函数，或深层模板嵌套，仍可能导致 DoS。
 
 ### memoryLimit