docs: add thread safety documentation to C API functions in ghostty.h

[daiimus]

Summary

Out of ~80+ exported C API functions in ghostty.h, only 2 have any thread safety documentation (ghostty_surface_write_output in Zig, and ghostty_surface_tmux_detach mentioning "Safe to call from any thread").

Functions like ghostty_surface_draw, ghostty_surface_set_size, ghostty_surface_set_focus, ghostty_surface_text, ghostty_surface_key, etc. all have implicit requirements about being called from specific threads, but this is never stated.

What's Needed

For each exported function, document:

1. Which thread(s) it can be called from (main thread, IO thread, any thread)
2. Which functions conflict with each other (cannot be called concurrently)
3. Data lifetime for pointer parameters and return values
4. Whether the function blocks or is async

Severity

MEDIUM — The iOS embedder must guess threading requirements. Mistakes cause subtle data races.

Source

Identified during code review of daiimus/ghostty:ios-external-backend.

[daiimus]

Assessment

Valid concern but largely upstream's responsibility. Out of 80+ exported C API functions, the vast majority are upstream code. The 2 documented cases (ghostty_surface_write_output and ghostty_surface_tmux_detach) are fork additions that we documented properly.

Documenting thread safety for all upstream functions is a large effort that would:

1. Create significant fork divergence (comment changes across thousands of lines)
2. Need to be maintained across rebases
3. Be better addressed upstream where it benefits all embedders (macOS, Linux, iOS)

Recommendation

Downgrade to p3-low. The practical impact is mitigated by the iOS embedder already following the correct threading conventions (Metal calls on main thread, IO-related calls on IO thread). The 2 fork-specific functions are already documented.

This is documentation debt, not a functional bug.