Fix xonsh xontrib in .xsh scripts and execx

[anki-code]

Summary

Resolves xonsh/xonsh#5823 and refs #883.

The xonsh xontrib only preprocessed code in xonsh's single parse mode (interactive REPL). When a .xsh script or execx(...) runs, xonsh compiles with mode="exec", so Coconut left |> alone and xonsh's parser then split it into | and >, eventually crashing in run_subproc with IndexError: list index out of range (xonsh/procs/specs.py:707).

#!/usr/bin/env xonsh
$(ls) |> .splitlines() |> len |> print   # IndexError before this PR

Changes

• coconut/constants.py — add "exec" to enabled_xonsh_modes so the xontrib hooks run for scripts and execx. xonsh already caches compiled .xsh bytecode via run_script_with_cache, and Coconut already memoizes parse_xonsh per process, so the original .xonshrc slowness from coconut makes .xonshrc take an unreasonable amount of time to load #724 stays mitigated.
• coconut/compiler/grammar.py — unsafe_xonsh_parser was built from single_input, which accepts only one statement, so multi-statement scripts failed with CoconutParseError: Expected end of text once exec was enabled. Switch to file_input (superset of single_input); single-statement input still parses correctly.
• coconut/tests/main_test.py — execx("10 |> print") previously asserted failure (subprocess mode / IndexError); it now succeeds and prints 10.
• DOCS.md — note that .xsh scripts and execx now work; only @(<code>) and evalx remain Python-only.
• coconut/root.py — bump DEVELOP.

Test plan

• Original issue repro: $(ls) |> .splitlines() |> len |> print from a .xsh script — works.
• Multi-statement script with 1 |> print, "hello" |> .upper() |> print, [1,2,3] |> sum |> print — all run.
• execx("10 |> print") — prints 10.
• Plain Python .xsh scripts and subprocess-mode commands (echo, ls) — no regression.
• Existing interactive REPL behavior (!(ls -la) |> bool, '1; 2' |> print, len("""1\n3\n5""")) — unchanged.
• Existing API assertions for parse(..., "xonsh") in extras.coco (lines 326–327) — still pass.