background-agent-api: Zig 0.15 HTTP parsing & ArrayList migration

[gHashTag]

Контекст

В рамках задачи #484 — background-agent-api Compile-Clean Pass уже сделано:

• railway/client.zig — GraphQL синтаксис исправлен.
• db/sessions.zig — unused captures, catch blocks исправлены.
• db/client.zig — все readAll() заменены на корректные read() с проверкой длины, readErrorResponse починен.
• server.zig — импорты RailwayClient, лишние переменные и brace mismatch исправлены.
• main.zig — std.log.info() приведён к новому API.
• config.zig — добавлено поле host.
• В CLAUDE.md добавлен раздел "Zig 0.15 API Compatibility and Migration Rules" с ссылкой на docs/zig-migration-rules.md.

После этих правок осталось 3–4 ошибки, которые относятся уже не к compile-clean, а к миграции API Zig 0.15.

Текущие проблемы

1. HTTP парсинг в src/background_agent/server.zig (строки ~110–166)

   • Использует старый SplitIterator API.
   • Логика опирается на .first() и .next() в стиле Zig 0.14.
   • В Zig 0.15 family итераторов изменился: .next() возвращает ?[]const u8 (optional), .first() ведёт себя по‑другому; простой orelse на не‑optional lhs больше не компилируется.
   • Требуется type‑driven рефакторинг HTTP request parsing (разбор Method PATH HTTP/1.1, заголовков и т.д.), а не синтаксические костыли.

2. Использование ArrayList в server.zig

   • ArrayList.init() / allocator model в Zig 0.15 изменились (error unions, явное управление allocator’ом).
   • Текущий код не соответствует новой сигнатуре и требует обновления по правилам миграции.

Scope этой задачи

Входит:

• Привести HTTP-парсинг в server.zig к корректному Zig 0.15 API:
  • Использовать актуальный итератор (splitScalar, splitSequence, tokenize*) строго по их документации.
  • Для каждой строки с .first() / .next():
    • явно определить тип возвращаемого значения ([]const u8 vs ?[]const u8);
    • использовать orelse только для ?T, catch — только для !T, согласно docs/zig-migration-rules.md.
• Обновить использование ArrayList:
  • Привести init / initCapacity / allocator handling к Zig 0.15.1 API.
  • Очистить error unions вокруг ArrayList согласно актуальной документации.

Не входит:

• Любые изменения PostgreSQL wire protocol (db/client.zig логика).
• Добавление новых фич HTTP сервера.
• Рефакторинг бизнес-логики background-agent-api (только API‑миграция).

Жёсткие правила (из CLAUDE.md)

Исполнитель обязан:

1. Перед каждым “migration fix”:
   • показать исходную строку;
   • указать тип левой части (?T, !T, !?T, и т.д.);
   • объяснить, почему используется именно orelse или catch (и ссылается на Zig docs / migration rules).
2. Запрещено:
   • придумывать операторы (??, и т.п.) или “новый синтаксис Zig” без официальных ссылок;
   • утверждать, что orelse “устарел” или “требует только error/noreturn”;
   • менять семантику HTTP‑парсинга ради того, чтобы “заставить компилироваться”.
3. Обязательно опираться на:
   • docs/zig-migration-rules.md;
   • Zig 0.15.1 docs: https://ziglang.org/documentation/0.15.1/
   • std docs: https://ziglang.org/documentation/master/std/
   • release notes 0.15.1: https://ziglang.org/download/0.15.1/release-notes.html

Критерии готовности

• zig build background-agent-api успешно завершается (exit code 0).
• HTTP‑парсер в server.zig:
  • корректно разбирает стартовую строку и заголовки;
  • не использует несуществующий API итераторов;
  • не падает на типах (orelse только на optionals, catch только на error unions).
• Использование ArrayList соответствует Zig 0.15.1:
  • никаких compile errors по init/allocator;
  • ошибки аллокации обрабатываются корректно.

Этот issue должен ссылаться на #484 как на родительскую compile‑clean задачу, но выполняется отдельно, как Zig 0.15 API migration pass.

[gHashTag]

Server.zig HTTP parsing already uses splitScalar/next() correctly and compiles with Zig 0.16.0. ArrayList usage is updated. All 2 tests pass. Migration complete.