refactor(ops)!: rename try_filter_map to try_map_filter

[0-jake-0]

Summary

Follow-up to #880 (which resolved #801), acting on two findings from its review. No release carries the old name, so nothing downstream breaks — this is free now and breaking later.

The rename

The catalog's fallible-twin convention is try_ plus the exact base name: map → try_map, join → try_join, join_passive → try_join_passive. The base here is map_filter, so the twin is try_map_filter. The op's own rustdoc already described it as "the try_ counterpart to map_filter" while carrying a name that said otherwise.

The concrete trap this removes is on the Signal facade, which already has a filter_map taking Fn(&T) -> Option<B>. Landing a try_filter_map taking Fn(&T) -> Result<(B, bool)> next to it put two methods side by side that read as an infallible/fallible pair and are not one — different shapes, different call sites, no relationship between them. try_map_filter sits beside map_filter, whose (value, emit?) shape it does mirror exactly.

Why rename rather than reshape to Result<Option<B>>. The dummy B on the reject path (Ok((B::default(), false))) is a real wart, but it is inherited from map_filter's (B, bool) shape — it is not introduced here. Giving the fallible twin an Option while the infallible one keeps a bool would make the pair less consistent, not more; matching shapes are what make "fallible twin" checkable at a glance. An Option-shaped convenience belongs on Signal, layered over this op exactly as Signal::filter_map layers over map_filter today. Happy to add that separately if wanted.

Also included, from the same review

• A Signal facade test (tests/signal.rs). The facade forward shipped with no test anywhere — deleting the __wf_signal_try_map_filter!(T) line left the build and the full suite green. That is exactly the facade drift the op recipe's step 4b records as having already cost 15 methods once. Verified the new test closes the hole: with the macro line removed the test crate now fails to compile (no method named try_map_filter found for struct Signal<T>).
• A disambiguating note on Signal::filter_map pointing at the shape difference, so the two neighbours explain themselves to the next reader.

Changes

• crates/wingfoil/src/ops.rs — TryFilterMap → TryMapFilter, build = try_map_filter
• crates/wingfoil/src/fluent.rs — StreamOps declaration and macro invocation
• crates/wingfoil/src/signal.rs — facade forward, plus the note on filter_map
• crates/wingfoil/tests/{catalog,fallibility,op_completeness}.rs — call sites and the msg.contains("TryMapFilter") assertion
• crates/wingfoil/tests/signal.rs — new legacy_try_map_filter_maps_and_filters

The generated macro names follow build = automatically, so __wf_fluent_try_filter_map! / __wf_signal_try_filter_map! become __wf_fluent_try_map_filter! / __wf_signal_try_map_filter! with no separate edit.

Test plan

• cargo fmt --all -- --check — clean
• cargo test -p wingfoil — full suite green (95 unit + all integration targets)
• cargo test --doc -p wingfoil — green; the new intra-doc link resolves (cargo doc --no-deps surfaces no new warnings)
• cargo test -p wingfoil-derive — green
• cargo lint (default features) — clean
• Confirmed no try_filter_map / TryFilterMap occurrences remain in the tree
• cargo lint-all / --all-features — not run here; this box has no protoc. The rename touches no feature-gated code, and CI's all-features leg covers it.

Note for #801

Issue #801 specified the name and the #[op(build = try_filter_map, fluent)] attribute verbatim, so @zaydmulani09 implemented exactly what was asked — this is a spec correction, not a defect in that PR. Worth editing the issue text if any of it is still being used as a template.

---

Generated by Claude Code