`read` builtin ignores custom IFS for field splitting

[chaliy]

Summary

The read builtin does not respect custom IFS for field splitting. When IFS is set to a non-default delimiter (e.g., , or :), read -r a b c puts the entire input into the first variable instead of splitting on the delimiter.

Reproduction

IFS=","; read -r a b c <<< "1,2,3"; echo "a=$a b=$b c=$c"
# expected: a=1 b=2 c=3
# actual:   a=1,2,3 b= c=

IFS=":"; read -ra arr <<< "x:y:z"; echo "${#arr[@]}"
# expected: 3
# actual:   1

Spec tests to add

### read_custom_ifs_comma
# read should split on custom IFS
IFS=","; read -r a b c <<< "one,two,three"; echo "$a|$b|$c"
### expect
one|two|three
### end

### read_custom_ifs_colon
# read -ra should split into array on custom IFS
IFS=":"; read -ra parts <<< "a:b:c"; echo "${#parts[@]} ${parts[1]}"
### expect
3 b
### end

Where to fix

The read builtin in crates/bashkit/src/interpreter/mod.rs or crates/bashkit/src/builtins/. When splitting input into variables, read should use the current IFS value (not hardcoded whitespace). Check self.get_variable("IFS") and split on those characters.

Real-world impact

High — IFS=: read -ra is the standard pattern for parsing delimited data (PATH splitting, CSV parsing, config files). The wedow/harness uses IFS=':' read -ra sources <<< "${HARNESS_SOURCES}" extensively.