inherit_env=True, consider documenting interpreter-level env vars aren't filtered

[lukehinds]

While working on the env hardening in #65, we block dynamic-loader vars (LD_*, DYLD_*, etc.) when the new inherit_env=True is used. That makes sense because those affect any binary universally.

There's a related class of vars we don't currently filter - interpreter-level ones like PYTHONPATH, NODE_OPTIONS, JAVA_TOOL_OPTIONS. These only matter if the child process happens to be that specific runtime, but since a lot of agent use cases are Python scripts, it's worth being upfront about it.

To be clear: the default (inherit_env=False) is completely unaffected - nothing leaks. This only comes into play if someone explicitly opts into inherit_env=True, which already implies they're consciously bringing in the parent environment.

A few options for how we handle this:

• Just document it — add a note to the inherit_env docstring that interpreter-level vars aren't filtered and callers should sanitise them if needed
• Add a second filter tier — extend is_dangerous_loader_env (or a sibling function) to also cover the common runtime vars
• Do nothing - arguably inherit_env=True is already an explicit trust decision, so the caller owns it - its doing what it says on the tin.