Bug Description

In the workflow expression evaluator, an unknown pipe filter is silently ignored — the value passes through unfiltered and the run completes with no error. Only five filters are registered (default, join, map, contains, from_json); any other filter name (a typo, or an unsupported one a user reasonably reaches for, e.g. length) is dropped silently, so the author gets a wrong value with no signal that the filter did nothing.

Root cause: src/specify_cli/workflows/expressions.py — the filter dispatch falls through to return value when no recognized filter matches (both the no-arg form and the unrecognized name(arg) form). This is the same "unknown-filter path" that the strict from_json handling already guards against for its own forms; it is unguarded in general.

Steps to Reproduce

1. Use an unregistered filter in a workflow expression, e.g. a shell step:

   - id: s
     type: shell
     run: "echo count={{ [1, 2, 3] | length }}"

2. specify workflow run <workflow>
3. The step prints count=[1, 2, 3] and the run completes — the length filter was silently ignored. (evaluate_expression("{{ [1,2,3] | length }}", ctx) returns [1, 2, 3], not an error or a count.)

Expected Behavior

An unregistered filter should fail loudly — a clear error naming the offending filter (and the valid ones) — so a typo or unsupported filter surfaces immediately instead of corrupting downstream expressions/conditions/gates silently. This matches the project's existing stance: from_json already raises on its mis-wired forms specifically to avoid "silently falling through to the unknown-filter path and returning the unparsed value," and fan-out items: was made fail-loud in #2957 for the same reason.

Actual Behavior

The unknown filter is silently dropped (return value); the expression yields the unfiltered value and the run reports success. No error, no warning.

Specify CLI Version

0.11.3

AI Agent

Claude Code

Operating System

macOS 14.5

Python Version

Python 3.11.15

Error Logs

(none — that is the bug: no error is raised; the filter is silently ignored)

Additional Context

Found while exercising workflow expressions end-to-end. Happy to send a small PR that makes the unknown-filter path raise (reusing the existing ValueError style from from_json), preserving all five registered filters.

AI disclosure: this issue was investigated and written with AI assistance (Claude Code); I reproduced and verified the behavior against the current tree myself.