fix(date): cap strftime widths and account padding in memoryLimit (#895)

* fix(date): cap strftime widths and account padding in memoryLimit

- Clamp numeric strftime pad widths to MAX_STRFTIME_PAD (1024)
- Export estimateStrftimePaddingMemory for the date filter to charge memoryLimit
- Replace unbounded pad() concatenation loop with ch.repeat + single concat
- Add regression tests for clamping and memoryLimit on huge %width directives

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

* fix(date): harden strftime memory accounting and document security model

Move strftime memory charging into the same formatting path used for padding, enforce pre-allocation checks, and add regression tests for non-string date format PoCs. Add dedicated docs clarifying that memoryLimit is cooperative DoS mitigation and not strict heap isolation.

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

* docs(zh-cn): add security model docs for DoS limits

Add a Chinese security-model tutorial and link it from the Chinese DoS guide to clarify that memoryLimit is cooperative accounting, list uncounted custom conversion cases, and recommend avoiding fully user-defined templates in online services.

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

* docs: consolidate DoS docs into security-model pages

Merge DoS guidance into security-model docs in both English and Chinese, and remove the placeholder dos.md pages to avoid duplicate/redirect-only docs.

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

* docs: merge DoS details into security-model docs

Move the detailed parseLimit/renderLimit/memoryLimit explanations and examples into the English and Chinese security-model pages so content from the removed dos pages is preserved.

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

* docs: reorganize security-model structure for clarity

Restructure English and Chinese security-model docs into a consistent flow: security boundary, limits overview, per-limit details, and online service guidance.

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

* refactor(strftime): simplify %N width parsing logic

Use regex-backed width assumptions to simplify %N width normalization and padding memory accounting while keeping behavior equivalent.

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

* 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]>

* fix(strftime): use add() once for padding, minimize churn

- pad(): replace per-char loop with a single add(str, ch.repeat(n)) call.
  The earlier `probe[0] === ch` heuristic was wrong when ch happened to
  equal a leading char of 'probe' (e.g. ch === 'p').
- strftime.ts: revert unrelated typing/structural refactors so the diff
  contains only the memoryLimit threading and the %N memory charge.
- docs: rewire the deleted dos.html sidebar entry to security-model.html
  (with localized labels) so the deleted page does not 404 from the
  sidebar.

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

---------

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

docs/source/tutorials/security-model.md

@@ -0,0 +1,76 @@
+---
+title: Security Model
+---
+
+LiquidJS provides DoS-oriented limits (`parseLimit`, `renderLimit`, `memoryLimit`) to reduce risk. This page explains what each limit protects, and the security boundary you should assume in production.
+
+## Security boundary
+
+The built-in limits are cooperative safeguards, not strict runtime isolation.
+
+- They do **not** equal process RSS/heap usage.
+- They do **not** sandbox JavaScript execution.
+- They should be combined with process/container limits and request timeouts for defense in depth.
+
+## Limits at a glance
+
+- [parseLimit][parseLimit]: limit total template size per `parse()` call.
+- [renderLimit][renderLimit]: limit total render time per `render()` call.
+- [memoryLimit][memoryLimit]: cooperatively limit memory-sensitive allocations counted by LiquidJS.
+
+## Limit details
+
+### parseLimit
+
+[parseLimit][parseLimit] restricts the size (character length) of templates parsed in each `.parse()` call, including referenced partials and layouts. Since LiquidJS parses template strings in near O(n) time, limiting total template length is usually sufficient.
+
+A typical PC handles `1e8` (100M) characters without issues.
+
+### renderLimit
+
+Restricting template size alone is insufficient because dynamic loops with large counts can occur in render time. [renderLimit][renderLimit] mitigates this by limiting the time consumed by each `render()` call.
+
+```liquid
+{%- for i in (1..10000000) -%}
+    order: {{i}}
+{%- endfor -%}
+```
+
+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.
+
+`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
+
+`memoryLimit` only limits operations that LiquidJS explicitly counts.
+
+- Counted: memory-sensitive LiquidJS operations that call internal memory accounting.
+- Not guaranteed counted: arbitrary user object behavior such as custom `toValue()`/`toString()` chains, or other host-side code that allocates outside LiquidJS accounting points.
+
+In other words, `memoryLimit` limits what LiquidJS counts, not every byte your process may allocate.
+
+Even with small number of templates and iterations, memory usage can grow exponentially. In the following example, memory doubles with each iteration:
+
+```liquid
+{% assign array = "1,2,3" | split: "," %}
+{% for i in (1..32) %}
+    {% assign array = array | concat: array %}
+{% endfor %}
+```
+
+As [JavaScript uses GC to manage memory](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_management), `memoryLimit` may not reflect the actual memory footprint.
+
+## Online service guidance
+
+If you run an online service, avoid rendering fully user-defined templates whenever possible.
+
+- Prefer curated templates or a restricted template subset.
+- If user-defined templates are required, isolate rendering (worker/process/container), enforce OS/container memory and CPU limits, and apply request rate limits.
+- Treat `parseLimit`/`renderLimit`/`memoryLimit` as one layer in a broader DoS defense strategy.
+
+For heavy single-template operations, process-level isolation is still recommended (for example with [paralleljs][paralleljs]).
+
+[paralleljs]: https://www.npmjs.com/package/paralleljs
+[parseLimit]: /api/interfaces/LiquidOptions.html#parseLimit
+[renderLimit]: /api/interfaces/LiquidOptions.html#renderLimit
+[memoryLimit]: /api/interfaces/LiquidOptions.html#memoryLimit