fix: reject nested vhs invocations instead of panicking

[arimu1]

Problem

Fixes #761.

Running vhs inside a tape that is itself being recorded (e.g. a tape that types vhs other.tape and hits Enter) starts a second ttyd + browser pair inside the first recording session. The inner instance shares the outer process's environment and races with the outer instance's own ttyd/browser lifecycle (port selection, process teardown, etc.). Depending on timing this crashes the whole program:

panic: write tcp 127.0.0.1:<port>->127.0.0.1:<port>: use of closed network connection

Repro from the issue:

1. inner.tape: any minimal tape (Output inner.gif, one Type/Enter).
2. outer.tape: Output outer.gif, Type "vhs inner.tape", Enter, Sleep 10s.
3. vhs outer.tape → panic.

I reproduced this locally (macOS, Chrome + ttyd 1.7.7) — nested rendering sometimes succeeds and sometimes fails, confirming it's a race rather than a deterministic error, consistent with the reporter's "reproduced twice" note on Windows/WSL.

Why full nested-rendering support is out of scope

Making nested rendering actually work would require isolating ttyd's port allocation, the browser's remote-debugging connection, and process teardown ordering between the outer and inner vhs instances — effectively giving each recording session its own sandboxed environment. That's a much larger change than a bug fix, and the issue reporter explicitly said a graceful error is an acceptable resolution.

Fix

• VHS.Start now exports VHS_RECORDING=1 into the environment of the shell/ttyd process it drives (tty.go), so any vhs invocation typed into that shell inherits it.

• Before launching ttyd/the browser, VHS.Start (vhs.go) checks for VHS_RECORDING and, if set, returns immediately with a clear error instead of proceeding:

  vhs is already recording; nested rendering is not supported

This fails fast before any ttyd/browser process is spawned for the inner instance, so there's nothing left to race or panic.

Testing

• go build ./...
• go vet ./...
• go test ./...
• Added TestStart_NestedRecordingRejected in vhs_test.go, which asserts VHS.Start returns the nested-recording error (and leaves vhs.started false) when VHS_RECORDING is set, without needing ttyd/a browser.
• Manually reproduced end-to-end with the tapes from the issue (built locally with ttyd 1.7.7 and Chrome installed): the outer tape now renders successfully and the recorded terminal shows the inner vhs invocation printing vhs is already recording; nested rendering is not supported and exiting with a non-zero status, instead of panicking.