Reject invalid tty_setattr actions before issuing a terminal ioctl

## Reproduced problem

The Unix `tty_setattr` helpers initialize their ioctl request to the immediate-set operation and only replace it for the two other recognized actions. Every other integer therefore silently acts like `TTY_TCSANOW`.

On a fresh Linux pseudo-terminal, `tty_setattr(fd, 99, &term)` returns **0**, after successfully reading that terminal's settings with `tty_getattr`.

```wave
import("std::sys::tty")::{Termios, tty_getattr, tty_setattr};
fun main() -> i32 {
var term: Termios;
if (tty_getattr(3, &term) < 0) { return 2; }
var status: i64 = tty_setattr(3, 99, &term);
println("invalid_action_status={}", status);
return 0;
}
```

Use `pty.openpty()` in a Python test, substitute the slave's descriptor for `3`, then execute the built binary with `pass_fds=(slave,)`. Close both PTY descriptors afterward. The audit used an isolated PTY and unchanged settings, not the user's terminal.

## Scope and acceptance

- [ ] Accept only `TTY_TCSANOW`, `TTY_TCSADRAIN` and `TTY_TCSAFLUSH`; return the provider's invalid-argument result for other actions before issuing an ioctl.
- [ ] Cover negative and positive invalid actions and preserve all three valid mappings.
- [ ] Add an isolated PTY regression proving an invalid request does not modify terminal settings.
- [ ] Apply the same validation to the implemented Linux, macOS and FreeBSD providers; distinguish native runtime checks from source/compile checks.
- [ ] Keep Windows console implementation work in #431 and introduce no libc FFI.

Start with `std/sys/linux/amd64/tty.wave::tty_setattr` and the corresponding architecture providers, `std/sys/macos/*/tty.wave`, and `std/sys/freebsd/common/tty.wave`. This is a small input-validation fix suitable for a first contribution.

Audited on canonical master `0c67f4cc0c3946cbf708c11ef79db927ec8f054e` (same source tree as #502 head). Executable reproductions used Fedora Linux amd64, Wave `0.2.1-pre-beta-dev`, LLVM 21.1.8.

Start with std/sys/linux/amd64/tty.wave::tty_setattr and compare the corresponding architecture providers, std/sys/macos/*/tty.wave, and std/sys/freebsd/common/tty.wave. Use the isolated pty.openpty() reproduction described in the issue, then verify negative and positive invalid actions are rejected before ioctl while all three valid mappings remain unchanged across the implemented providers.

Written by the indexing model from the issue text.