[Feature]: expand expression evaluator filter set (upper, lower, length, split, sort, to_json)

Start in src/specify_cli/workflows/expressions.py, reading the existing filter registration and _apply_filter() implementation around lines 20-26 and 419-484. Then inspect tests/test_workflows.py and the existing filter tests to understand input and error conventions. The work is done when the agreed filter set is registered, implemented, and covered by tests, including the unresolved length semantics and naming decisions.

Problem

The workflow expression evaluator currently supports only 5 filters: default, join, map, contains, and from_json. For a system marketed as "Jinja2-like," common string and collection operations are missing, forcing workflow authors to shell out for basic transformations.

Missing filters that workflow authors frequently need:

• String operations: upper, lower, trim (whitespace), split (string to list)
• Collection operations: length, first, last, sort, unique
• Serialization: to_json (the reverse of existing from_json)

Example of current limitation:

# Cannot do this today — no `length` filter:
- id: check
  type: shell
  config:
    command: "echo 'Found {{ items | length }} files'"

# Cannot do this today — no `split` filter:
- id: list
  type: shell
  config:
    command: "echo '{{ file_list | split(\",\") | length }} files found'"

Proposed Solution

Add a batch of new filters to the expression evaluator, following the existing registration pattern.

String Filters

Collection Filters

Serialization Filter

Design Notes

• Follows existing pattern: Each filter is a standalone function registered in _REGISTERED_FILTERS and dispatched in _apply_filter() (expressions.py lines 20-26, 419-484)
• Safe by design: All operations are pure transformations — no arbitrary code execution, no side effects, consistent with the sandboxed evaluator model
• length enables conditionals: Unlocks {% if items | length > 0 %} patterns that currently require shell workarounds
• split bridges shell output: Shell steps return newline/comma-separated strings; split converts them to lists for downstream processing
• to_json completes the round-trip: from_json exists; to_json is its natural pair for passing structured data back to shell commands

Affected Files

• src/specify_cli/workflows/expressions.py — filter registration and implementation (lines 20-26, 419-484)
• tests/test_workflows.py — unit tests for each new filter

Questions

1. Are there additional filters you would want in this batch, or should we start with a smaller set?
2. Should length work on both lists and strings (Jinja2 behavior), or only collections?
3. Any naming preferences (e.g., len vs length, flatten vs unique)?

Happy to implement if this aligns with your plans for the expression engine.