tab after pipe or && completes from $PWD instead of $PATH

[Fanteria]

brush version

brush 0.4.0 (git:d597d2b)

bash version (for comparison)

GNU bash, version 5.3.9(1)-release

Platform / OS

Linux

Steps to reproduce

# Create a file that starts with a common command prefix so the wrong behaviour is visible
touch /tmp/grepping_file

cd /tmp
brush
ls | gr<TAB>        # completes 'grepping_file' instead of 'grep', 'groups', etc.
true && ec<TAB>     # completes nothing useful instead of 'echo', 'expr', etc.

Actual behavior (brush)

Completions are sourced from $PWD (file/directory names), so only files whose names happen to share the prefix are offered. When no such files exist, nothing is suggested at all.

Expected behavior

After a command separator the next token is in command position. Tab completion should offer commands (builtins, shell functions, aliases, and $PATH executables) the same candidates that appear when completing the very first word on the line.

ls | gr<TAB>    # grep, groups, etc.
true && ec<TAB> # echo, expr, etc.

Additional context

In brush-core/src/completion.rs function get_completions_using_basic_lookup:
is_command_position was computed as token_index == 0, so only the very first token ever received command completions. Tokens after a separator always have an index > 0 in the flat token list and fall through to file completions. There is even a TODO comment in the code acknowledging this:

// TODO(completions): Do a better job than just checking if index == 0.
let is_command_position =
    context.token_index == 0 && !token.is_empty() && !sys::fs::contains_path_separator(token);

[Fanteria]

I've submitted a fix for this in #1159.