`Control-j` remapped in `.inputrc` causes bash commands to hang (all except possibly the first)

### Describe the bug

When a user has `Control-j: next-history` (or any other non-default binding for `Control-j`) in their `~/.inputrc`, commands executed by Copilot CLI hang indefinitely and produce no output. The shell session appears to start correctly but never executes the command. Copilot CLI surfaces this to the user as:

> `Invalid shell ID: 1. Please supply a valid shell ID to read output from.`

This happens because `Control-j` is ASCII linefeed (LF, `\n`) — the character readline uses internally to signal "execute this line." Remapping it to any other action (like `next-history`) removes readline's ability to run commands, breaking all Copilot CLI bash sessions.

**Curious side effect:** The very first command in a fresh Copilot CLI session sometimes succeeds. This appears to be a race condition — the command is dispatched before readline finishes initializing and applying `.inputrc`. Every subsequent command in the same session fails.

Related issues:
- https://github.com/github/copilot-cli/issues/731
- https://github.com/github/copilot-cli/issues/1161
- https://github.com/github/copilot-cli/issues/1838

### Affected version

1.0.49

### Steps to reproduce the behavior

1. Add the following line to `~/.inputrc`:
```
Control-j: next-history
```
2. Open a new Copilot CLI session
3. Ask Copilot CLI to run any bash command (e.g. `echo hello`)
4. Observe: the command hangs indefinitely, eventually timing out with no output

**Note:** The very first command in the session may occasionally succeed due to a race condition between command dispatch and readline initialization.

### Expected behavior

Copilot CLI should execute bash commands successfully regardless of the user's `~/.inputrc` configuration. User readline customizations are personal preferences and should not affect Copilot CLI's ability to run shell commands.

### Additional context

**Workaround (for users):**

Wrap the binding in an `$if` conditional in `~/.inputrc`, scoped to your interactive terminal's `$TERM` value (e.g. `xterm-256color` or `screen-256color`):

```
$if term=screen-256color
Control-j: next-history
$endif
```

Note: Copilot CLI spawns bash with `$TERM=xterm-color`, so the binding won't apply to its sessions when scoped this way.

**Suggested fix (for the Copilot CLI codebase):**

Copilot CLI should isolate its bash sessions from the user's readline configuration. Any of the following approaches would fix the issue:

1. **Set `INPUTRC` to an empty temp file** when spawning bash — prevents `.inputrc` from being loaded entirely for Copilot CLI sessions
2. **Spawn bash with `--noediting`** — disables readline for that session, so `.inputrc` is never applied
3. **Spawn bash as non-interactive** (`bash -c "..."`) — non-interactive sessions don't load readline at all, making them immune to `.inputrc` customizations

Option 3 is likely the cleanest since Copilot CLI doesn't need an interactive readline-enabled shell — it just needs to execute commands and capture output.

**Bash version used**:
```
GNU bash `5.3.0(1)-release` (x86_64-redhat-linux-gnu)
```