# Исправление gRPC deadline для T-Bank портфеля

## Контекст

При запросе брокерского портфеля T-Bank бэкенд дополнительно обогащает позиции через
`InstrumentsService/GetInstrumentBy`. Для портфеля с несколькими позициями эти запросы запускаются пачкой,
но `TBankClientService` пропускает реальные gRPC-вызовы через локальный `PQueue` rate limiter.

Сейчас `deadline` создаётся до постановки задачи в очередь. Если вызов ждёт rate limiter, время ожидания
съедает `T_BANK_REQUEST_TIMEOUT_MS`, и gRPC может завершиться мгновенным
`DEADLINE_EXCEEDED after 0.000/0.001s` ещё до сетевого запроса.

## Цель

Сделать так, чтобы локальное ожидание в `PQueue` не расходовало gRPC deadline, а сбой обогащения отдельного
инструмента не ломал весь ответ портфеля.

## Границы

- Не менять публичный API `/api/v1/broker/accounts/:accountId/portfolio`.
- Не менять значения переменных окружения и конфигурацию rate limiter.
- Не добавлять retry/backoff в этом исправлении.
- Не менять стратегию кеширования инструментов.

## Acceptance criteria

- `TBankClientService.callUnary()` создаёт `Metadata` и `deadline` непосредственно перед фактическим
  gRPC-вызовом внутри задачи `PQueue`.
- `T_BANK_REQUEST_TIMEOUT_MS` измеряет время выполнения upstream gRPC-вызова, а не время ожидания локальной
  очереди.
- Есть regression test, который доказывает, что второй queued-вызов получает deadline после ожидания очереди.
- `BrokerPortfolioService` строит карту инструментов best-effort: ошибка одного `GetInstrumentBy` не роняет
  весь портфель.
- Есть regression test, который доказывает, что портфель возвращается, если один инструмент не удалось
  обогатить.

## Проверка

- Targeted tests:
  `npm run test -w apps/backend -- src/modules/tbank/services/tbank-client.service.spec.ts src/modules/tbank/services/broker-portfolio.service.spec.ts`
- Full backend tests:
  `npm run test:backend`