Feature request: Add option to disable `_check_bash_command` syntax pre-check in `/run_in_session`

[nier-scitix]

Motivation

Currently, BashSession._run_normal() uses bash -n to validate commands before execution. While intended to prevent session hangs, this pre-check is too aggressive and problematic for programmatic use cases:

1. False Positives: Valid but complex commands (especially those involving nested awk, sed, or multi-line strings) are occasionally flagged as syntax errors by the heredoc-based check, even though they would run fine in a real shell.
2. Inconsistent Error Feedback: When a syntax error is real, the system raises a BashIncorrectSyntaxError (HTTP 511) instead of allowing the bash session to return the actual standard error (e.g., bash: syntax error near...). This prevents the caller from receiving authentic shell feedback.
3. Redundancy: The existing action.timeout and pexpect buffer management are generally sufficient to handle hung sessions.

We understand this was introduced in PR #63 (addressing Issue #25) to ensure session stability. However, for many automated workflows, the pre-check acts more as a barrier than a safeguard.

Proposed Changes

Add a way to bypass _check_bash_command, such as:

• An environment variable: SWEREX_DISABLE_SYNTAX_CHECK=1
• A server-side flag: --no-syntax-check

Reproduction

The following common patterns are currently blocked before execution:

# These raise BashIncorrectSyntaxError but should be handled by the shell itself
commands = [
    "echo 'unclosed quote", 
    "if [ -f file ]; then echo 1", # Missing 'fi'
    "cat file | | grep pattern"    # Empty pipe
]

By allowing these to execute, the user receives the raw stderr from the environment, which is often more useful than a generic 511 exception.