docs: document hourly investment reads

architecture/http-api.md

@@ -2,7 +2,8 @@
 
 ## Источник контракта
 
-Backend генерирует OpenAPI из собственного публичного API. Frontend использует
+Backend генерирует OpenAPI из собственного публичного API. Этот сгенерированный
+OpenAPI — исполняемый источник HTTP-контракта. Frontend использует
 предоставленный OpenAPI snapshot как актуальный вход и локально генерирует
 типизированный клиент. Backend владеет контрактом, а подготовка и доставка
 схемы находятся вне frontend. Это разделение принято в
@@ -22,27 +23,27 @@ environment policy, а не используется frontend в runtime.
 
 ## Инвестиционные данные и синхронизация
 
-T-Bank data GET возвращают envelope `{ data, meta }`. `data` может быть `null`
-при missing или неполном финансовом агрегате; partial ledger/candles могут
-содержать подтверждённые строки. `meta` разделяет availability, freshness,
-lastSuccessfulAt, sync, coverage и состояния зависимостей. `dataRevision`
-описывает набор данных; пустое завершённое покрытие явно представлено в coverage.
-Публичной hash-версии состояния нет. Ни одно поле не раскрывает connection revision.
+Затронутые GET инвестиционных ресурсов возвращают сгенерированный contract
+`{ data, meta }`. `data` nullable: `null` означает отсутствие complete result,
+а подтверждённый пустой массив является available complete result. `meta`
+независимо описывает freshness, completeness, `lastSuccessfulAt`,
+resource-relevant `lastAttempt` и availability. `lastAttempt` имеет состояния
+`none`, `running`, `succeeded`, `partial` и `failed`; его неуспех не заменяет
+сохранённый complete result или его время. `Portfolio.isStale` остаётся
+специфичным для snapshot полем, а не заменой состояния попытки.
 
-Обычный GET планирует missing/stale зависимости после проверки доступа.
-GET с `sync=observe` только читает. `POST /api/v1/tbank-sync` принимает
-валидированный screen descriptor и возвращает `202` с handle и нормализованным
-scope. `GET /api/v1/tbank-sync/:id` наблюдает разрешённую работу; чужой или
-прежний handle возвращает `404`. Приём работы не означает её успех.
+Только Accounts дополнительно возвращает top-level `sync`: `null`, если у
+текущего подключения ещё не было часовой попытки, иначе connection-wide
+наблюдаемый результат. Это наблюдение, не команда. Обычный GET и retry после
+проверки доступа читают локальное состояние и не начинают личную работу.
+Устаревший `sync=observe`, пока он сохранён для совместимости маршрута, также
+только читает. Request-started screen-sync command/status не является текущей
+AS-IS моделью.
 
-Status возвращает state/errorCode без данных ресурсов и численных progress
-counters. Клиент перечитывает показанные resources через `sync=observe` во время
-работы и после завершения, сохраняя generated query identity. Sync states ресурса:
-`idle`, `running`, `failed`; отдельного публичного `queued` нет.
-
-Source failure принятой работы передаётся безопасным `meta.sync.errorCode`;
-HTTP transport/access/input errors сохраняют Problem Details. Старые данные
-при transient failure сохраняют исходное успешное время. Детали поведения —
+Безопасные ошибки завершённой часовой попытки передаются в `lastAttempt` и
+Accounts `sync`; HTTP transport/access/input errors сохраняют Problem Details.
+Старые данные при временной source failure сохраняют исходное успешное время.
+Ни одно поле не раскрывает connection revision. Детали поведения —
 [свежесть и полнота](cross-cutting/data-freshness.md).
 
 Envelope несовместим с прежними bare-array ответами: backend/frontend