Document internal C API contracts and IR string equality conventions

Summary

Addresses #181.

This PR addresses #181 by documenting the internal C API contract vocabulary, pointer access effects, ownership/lifetime conventions, boundary expectations, and observed IR string equality behavior. It also records unresolved contract debt.

The change is documentation/comment-only.

What changed

• Added internal C contract documentation under native/zero-c/docs/internal-c-contracts.md.
• Documented contract vocabulary such as in, inout, out, opt out, sink, return owned, return borrowed, retains, no-retain, nullable, non-null, alias ok, and no alias.
• Added targeted contract comments around public/internal C boundaries in zero.h.
• Added targeted comments in checker.c for checker boundary behavior and source-backed AST annotation mutation.
• Added targeted comments in ir.c for IR lowering, lookup helpers, string equality sites, ownership/copy behavior, and destructor behavior.
• Documented why IR currently deals with strings based on observed source behavior.
• Documented observed IR string equality as value equality where source shows strcmp, strncmp, or equivalent comparison.
• Recorded unresolved follow-up questions with stable contract debt IDs.

Scope

This PR does not change:

• compiler behavior
• parser behavior
• checker behavior
• IR representation
• code generation
• function signatures
• public CLI behavior
• dependencies
• lockfiles
• build scripts

Validation

• Confirmed the committed scope is limited to four documentation/comment files.
• Confirmed the C diff is comment-only, with no executable code, declarations, signatures, includes, macros, or behavior changes.
• Confirmed no local validation artifacts are included in the public repository.
• Local validation passed using the native Zero CLI through a custom validation harness with strict scope separation, receipt capture, and independent review.

Notes

The IR string section intentionally documents current observed behavior only. It does not claim string interning, canonical symbolic identity, or future symbol-handle design. Those are recorded as follow-up design questions where appropriate.