fix: make -f w compose with other flags and bind to the whole pattern

[vlasky]

-f w has three independent bugs. All three are silent: wrong result, exit status 0, no diagnostic. There is no existing issue for them, so the report is inline below.

Two mistakes are packed into the one 'w' arm of the flag loop: it replaces the whole RegexBuilder instead of setting an option on it, and it splices \b into the pattern with no grouping.

let mut regex = regex::bytes::RegexBuilder::new(&look_for);
regex.multi_line(true);                      // <-- applied BEFORE the loop
// ...
'w' => {
    // constructs a NEW builder; everything set on the old one is gone
    regex = regex::bytes::RegexBuilder::new(&format!("\\b{}\\b", look_for));
},

1. Flags to the left of w are discarded

Assigning a fresh builder throws away everything set on the previous one, so -f iw and -f wi differ, even though --help documents flags as freely combinable ("May be combined (like -f mc)") and says nothing about order:

$ echo "FOO bar" | sd -f iw 'foo' 'X'
FOO bar          # 'i' discarded, no match, exit 0
$ echo "FOO bar" | sd -f wi 'foo' 'X'
X bar            # works

Same for s, and for an i set before a c.

2. w disables multi-line matching, unrecoverably

multi_line(true) is applied before the loop, so w discards that too, and nothing puts it back: the 'm' arm is a no-op because multi-line is meant to be the default. There is no way to get word-boundary matching and multi-line anchoring at once. On printf 'aa\nbb\n' replacing ^\w+ with M:

Invocation	Result
(none) / -f m	M\nM
-f e	M\nbb (as documented)
-f w / -f wm / -f mw	M\nbb (m does not restore it)

Since #328 made line-by-line the default this needs -A to observe, because per-line anchoring holds either way when input is fed one line at a time. Before #328 it was reachable with no flag at all, and it has been present since 87491b4 (2020) introduced the pre-loop multi_line(true).

3. \b binds to the first and last alternative, not the whole pattern

Independent of the above, and the oldest: it dates to 80d92bd (2019), where w was introduced. | binds looser than concatenation, so foo|bar becomes \bfoo|bar\b, which parses as (\bfoo)|(bar\b). Only the first alternative gets a leading boundary and only the last gets a trailing one; with three or more, the middle ones get neither.

$ echo "foox bar" | sd -f w 'foo|bar' 'X'
Xx X             # replaced the "foo" inside "foox"

This is the opposite of the documented "match full words only": the flag broke the guarantee it advertises, and made a replacement that plain sd 'foo|bar' 'X' would also have made. It is also worse than the other two: they silently do nothing, this silently does something unwanted.

Fix

Resolve w into the pattern before the builder is constructed, so the builder is built exactly once and no state can be discarded, and wrap in a non-capturing group so \b binds to the whole pattern:

let word_boundary = flags.as_deref().is_some_and(|f| f.contains('w'));
let pattern = if word_boundary {
    format!("\\b(?:{look_for})\\b")
} else {
    look_for
};

(?:...) rather than (...) matters: a capturing group would renumber the user's own groups and break sd -f w '(f)(o)o' '$2$1'. There is a test for that.

Flag order is now irrelevant, which is what the help text already promises.

Tests

w had one test since 2019 (look_for: "abc", flags: Some("w")). That case cannot catch any of the three, structurally: abc has no top-level |, w is never combined with another flag, and there is no anchor or newline. This adds six example tests and two proptests:

• -f iw / -f wi both case-insensitive; -f sw / -f ws both dot-matches-newline
• -f w / -f wm / -f mw keep ^ and $ anchoring
• foo|bar anchors all alternatives (3 inputs)
• -f w '(f)(o)o' with $2$1 does not shift capture groups
• -f w alone still word-bounded and case-sensitive (regression guard)
• proptest: w's position in the flag string is irrelevant (the rest of the string keeps its order, so genuine last-one-wins conflicts resolve identically and only w moves)
• proptest: -f <S>w on P equals -f <S> on \b(?:P)\b, i.e. w only adds boundaries

Of the six example tests, three fail against unfixed mod.rs (one per bug) and three pass either way as regression guards. Both proptests also fail against unfixed mod.rs. Full suite passes; cargo clippy --all-targets --all-features and cargo fmt --check -p sd are clean.

Notes

• Bug 2 is arguably a behaviour change for anyone relying on -f w disabling multi-line, but that was undocumented and almost certainly unintended.
• No docs change: the help text, README and man page never described the broken behaviour, so there is nothing to correct.
• Branched off master, independent of feat: reject replacement references to undefined capture groups #346 and feat: add --must-match to exit non-zero when nothing matched #347. Will need a trivial rebase if feat: reject replacement references to undefined capture groups #346 lands first, since it moves this code into build_regex.
• Unrelated and left alone: m cannot re-enable multi-line after an e; s disables multi-line as an undocumented side effect; unknown flags (-f z) are silently ignored. Happy to open separate issues if useful.