envd: distinguish expected stdin lifecycle errors from CodeInternal

[wangxuw]

Problem

Process.SendInput currently maps every Handler.WriteStdin failure to
CodeInternal.

Some of these failures are expected process lifecycle outcomes:

• stdin is disabled or already closed;
• a PTY process receives stdin input;
• the process exits and its stdin pipe returns EPIPE/file-already-closed.

CodeInternal is reserved for serious invariant failures, so clients cannot
distinguish a normal process-state transition from an unexpected envd failure.

This also races with the Start response stream: SendInput can return
CodeInternal before the process's EndEvent arrives on the independent stream.

Proposed semantics

• process selector no longer exists: CodeNotFound
• process exists but cannot accept stdin: CodeFailedPrecondition
• unexpected underlying I/O failure: CodeInternal

CloseStdin should follow the same error taxonomy.

The EndEvent remains authoritative for exit status; a SendInput error alone
must not be treated as the terminal process result.

Compatibility

This changes observable Connect error codes, although callers that only check
for a non-nil error are unaffected. Python and JavaScript SDK behavior should
be checked before merging.

Reproduction

Start a short-lived non-PTY process, wait for its stdin pipe to close, then
call SendInput before the delayed EndEvent is delivered. The current service
returns CodeInternal for the closed pipe.