filter blocks apply the filter to already-escaped input-marked text

[leehack]

A {% filter %} block, or a block {% set %} passed through a filter, applies the filter to text that is already HTML-escaped. So a JinjaString.user value in the body reaches the filter as <b>, not <b>. {{ x | upper }} filters first and escapes after. This has been the case since before #26: base 74d487e and head b3eaffc give the same output.

Repro, x = JinjaString.user('<b>') in dinja, x = '<b>' elsewhere:

Template	dinja base 74d487e	dinja #26 head b3eaffc	llama.cpp 7fe450e1	Jinja2 3.1.6, autoescape=False	Jinja2 3.1.6, autoescape=True
{% filter upper %}{{ x }}{% endfilter %}	&LT;B&GT;	&LT;B&GT;	<B>	<B>	&LT;B&GT;
{{ x | upper }}	&lt;B&gt;	&lt;B&gt;	<B>	<B>	&lt;B&gt;
{% set s %}{{ x }}{% endset %}{{ s | upper }}	&LT;B&GT;	&LT;B&GT;	<B>	<B>	&LT;B&GT;
{% filter replace("b", "i") %}{{ x }}{% endfilter %}	&lt;i&gt;	&lt;i&gt;	<i>	<i>	&lt;i&gt;
{% filter length %}{{ x }}{% endfilter %}	9	9	3	raises TypeError	raises TypeError

Jinja2 runs as SandboxedEnvironment(trim_blocks=True, lstrip_blocks=True). llama.cpp marks input but never HTML-escapes it, so it has no escaped column; it filters the raw text.

Notes

• dinja's output equals Jinja2's with autoescape=True for upper, set and replace: there a filter block's body is Markup, and filters run on the escaped text. So "filter the raw input, then escape" is a choice to make, not the only reading.
• The clearest mismatch is that a filter sees the escaped text. length counts <b> (9) where llama.cpp counts <b> (3). The same goes for any filter that inspects content, such as replace on <, truncate or wordcount.
• Only JinjaString.user values are affected; plain strings are never escaped. Among the 86 real templates checked for fix: lstrip_blocks, strftime_now, loop controls, caller() and filters on none #26, the only filter block is firefunction-v2's {%- filter trim -%}, and it wraps static text with no expressions.