Implement std/os package for env/process/fs primitives

[emil14]

Summary

• expand std/os from Args/Environ to a practical typed surface for environment, process, filesystem, and temp-path operations
• add runtime function implementations for new #extern bindings and register them in internal/runtime/funcs/registry.go
• fix args runtime function list construction bug (pre-sized slice + append)
• add targeted unit tests for new runtime helpers and a focused e2e package for std/os

Design notes

• kept this iteration value-oriented and dataflow-friendly (path/key/value/perm inputs + typed outputs)
• intentionally avoided introducing stateful file-handle API in this PR to keep semantics explicit and composable in static dataflow
• query-style components without natural data input are signal-triggered (sig) to avoid autonomous senders

Validation

• golangci-lint run ./internal/runtime/funcs/... ./e2e/os_package/...
• go test ./internal/runtime/funcs/... ./e2e/os_package
• golangci-lint run ./...
• go test ./... (broad run started and progressed through many e2e packages; targeted changed-package suites fully passed)

Part of #1033
Closes #586

[emil14]

Review Summary

Critical Issues (Blocking)

• internal/runtime/funcs/os_helpers.go:191: runBinaryLoop receives from firstIn before it starts waiting on secondIn. That changes the dataflow/backpressure semantics for every new two-input std/os component using this helper (Setenv, Mkdir, MkdirAll, Rename, Truncate, MkdirTemp, CreateTemp): if the second input is produced first, or if producing the first input depends on the second branch being drained, the component can deadlock even though both inputs would eventually be available. Existing binary runtime funcs use receive2(ctx, firstIn, secondIn) to arm both receives concurrently. Please switch runBinaryLoop to receive2 and add a regression test that proves the second input can arrive before the first without blocking.