Emit constant templates and rebase the result in the pure sink's pattern arm

[imlvts]

Two follow-ups to the compound-capture arm added in trueagi-io#137. Both produce a wrong answer rather than a panic, so neither is caught by that arm's existing tests.

A constant template emitted nothing

(exec 0 (,) (O (pure yes 321 (reverse_symbol 123))))

reverse_symbol(123) is 321, so the guard accepts — and the result is then dropped. The trace shows the guard was never the problem:

pure at 'yes 321 [2] reverse_symbol 12<truncated 1>'
pure registering in ctx "[51]"
pattern guard result "321"          <- evaluated and matched
pure template within its request root, skipping

request() took the write root from the prefix of the whole (pure <template> <pattern> <call>). That coincides with the template's own prefix only while the template holds a variable — the prefix stops there and never reaches the pattern. With a constant template it runs past the template into the pattern and the call, so the root covers the entire expression and there is nothing below it to write.

The root now comes from the template alone (in the stacked commit below), so an instantiation always extends it by at least one byte and the pbuffer.len() > rooted skip becomes a debug_assert.

This was reachable by exactly the idiom the arm advertises. sink_pure_symbol_guard only passes because (ok $i) happens to carry a query-bound variable; write the same guard without one and it silently emits nothing.

The result was unified in a fresh namespace (trueagi-io#135)

eval preserves the numbering of the expression it was handed, so a variable introduced inside the call comes back carrying its index in the sink expression's namespace, not one relative to the result. Unifying it as standalone leaves the reference dangling, and a dangling reference prints as a fresh variable — ($a $a) came out as ($a $b). The result is a subexpression of the stored triple, so it now takes call_env.v as its de Bruijn base, which subterms already computes. One line.

Benchmarks

Re: benchmarking the pure sink specifically — mork bench pure runs both capture arms and the rejecting guard over one workload (100k rows, one tuple evaluation each), so the specialization is a measurement rather than an argument:

arm	unifications	writes	transitions	wall
var (specialized)	100001	100000	100007	132–136 ms
compound (generic)	100001	100000	100008	173–181 ms
guard (rejecting)	200000	100000	200006	~133 ms

The two arms are within one transition of each other, but the specialization is consistently ~25% faster in wall clock (min of three interleaved runs). So it earns its place for reasons the deterministic counters don't capture — which is also why trueagi-io#135 is fixed once per mechanism here rather than by folding the arms together. Counters are reported as deltas because they're process-cumulative statics.

No regression: process_calculus unifications 201401, instructions 427949817; counter_machine steps 1813 size 2753; both unchanged.

Tests

• sink_pure_constant_template_guard — constant symbol and constant compound templates, with three controls that separate "the guard rejected" from "the template was dropped": an accepting guard with a variable template, a constant template through the NewVar arm, and a rejecting guard with a variable template.
• sink_pure_compound_quoted_variable_identity — Quotation does not handle variable reference correctly trueagi-io/MORK#135 through this arm.