Use of `sh -i` in desk run causes process suspension in pipelines

This makes desk unusable in some pipelines (or any pipelines if you don't like guessing).

This is a little complicated to reproduce. For instance, changing the first command from `ls` to `seq 10` usually succeeds. I'm not sure what the reason is here, but it is likely related to the fact that `seq` can produce output sooner than `ls`.

```bash
:; desk run hello ls | desk run hello tac
[hangs]^C
[1]+ Stopped desk run hello ls | desk run hello tac
:; fg
desk run hello ls | desk run hello tac
[exits]
```

Or, if run with no controlling tty, we get warnings but the pipeline is otherwise functional.
```bash
:; desk run hello ls | desk run hello tac
bash: cannot set terminal process group (6214): Inappropriate ioctl for device
bash: no job control in this shell
bash: cannot set terminal process group (6211): Inappropriate ioctl for device
bash: no job control in this shell
[correct output follows]
```

I think this all has something to do with multiple shells trying to manage the foreground process on the terminal. This can be avoided if `desk run` stops using the `-i` flag and simply injects `. $DESK_ENV;` in front of the command to run.

Start at the desk run entry point and reproduce the reported `desk run hello ls | desk run hello tac` pipeline in a terminal and without a controlling TTY. Inspect how `desk run` invokes `sh -i`; done means the pipeline completes without suspension or job-control warnings while preserving the expected output.

Written by the indexing model from the issue text.