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/source/tutorials/dos.md

@@ -8,6 +8,8 @@ When the template or data context cannot be trusted, enabling DoS prevention opt
 
 Setting these options can largely ensure that your LiquidJS instance won't hang for extended periods or consume excessive memory. These limits are based on the available JavaScript APIs, so they are not precise hard limits but thresholds to help prevent your process from failing or hanging.
 
+For the security boundary and production hardening guidance, see [Security Model][security-model].
+
 ```typescript
 const liquid = new Liquid({
     parseLimit: 1e8, // typical size of your templates in each render
@@ -54,4 +56,5 @@ Even with small number of templates and iterations, memory usage can grow expone
 [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
+[memoryLimit]: /api/interfaces/LiquidOptions.html#memoryLimit
+[security-model]: /tutorials/security-model.html

docs/source/tutorials/security-model.md

@@ -0,0 +1,30 @@
+---
+title: Security Model
+---
+
+LiquidJS provides DoS-oriented limits (`parseLimit`, `renderLimit`, `memoryLimit`) to reduce risk, but these limits are cooperative safeguards, not strict runtime isolation.
+
+## `memoryLimit` is cooperative
+
+`memoryLimit` tracks memory-sensitive allocations inside LiquidJS code paths that explicitly account for them. It is best-effort mitigation for template-driven abuse, not a strict heap cap.
+
+- It does **not** equal process RSS/heap usage.
+- It does **not** sandbox JavaScript execution.
+- It should be combined with process/container limits and request timeouts for production defense-in-depth.
+
+## What it limits (and what it does not)
+
+`memoryLimit` only limits operations that LiquidJS itself 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.
+
+## Guidance for online services
+
+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.