…ation (TRST-L-1)

The validation warnings for low trigger values and max_amount_willing_to_lose
were never triggering due to incorrect float-to-u128 conversion.

Previously, floating-point literals like `0.1` were converted to u128 via
`.to_u128()`, which truncates to 0 since u128 cannot represent fractions.
This meant comparisons like `trigger_value < 0` were always false.

Fix:
- Replace `0.1f64.to_u128()` with proper wei constant (0.1 GRT = 10^17 wei)
- Replace `0.001f64.to_u128()` with proper wei constant (0.001 GRT = 10^15 wei)
- Remove unused `FromStr` import

This only affects startup warnings, not runtime behavior. Operators with
misconfigured low values will now correctly receive warnings.

Add explicit validation to reject zero values for Duration configuration
fields that would cause incorrect behavior or system failures:

- subgraphs.escrow.syncing_interval_secs
- subgraphs.network.syncing_interval_secs
- tap.rav_request.request_timeout_secs
- tap.sender_timeout_secs
- subgraphs.network.recently_closed_allocation_buffer_secs

Note: timestamp_buffer_secs intentionally not validated as zero is a valid
(though not recommended) value meaning "no buffer".

Addresses: TRST-L-2

Add validation that warns when authentication tokens are configured
with non-HTTPS URLs, which could expose credentials to interception
via man-in-the-middle attacks.

The warning is suppressed for localhost/127.0.0.1/::1 to allow
local development workflows without noise.

Affected configurations:
- subgraphs.network.query_auth_token with non-HTTPS query_url
- subgraphs.escrow.query_auth_token with non-HTTPS query_url

Addresses: TRST-L-3

Add documentation explaining why is_horizon_active() always returns true:
during migration, zero PaymentsEscrow accounts does not indicate Horizon
is inactive - contracts may be deployed before any deposits are made.

Mark the function as deprecated since the network has fully migrated to
Horizon and this detection is no longer necessary.

Addresses: TRST-L-5

Add documentation explaining why paid query responses always return
HTTP 200 OK regardless of graph-node's status code. This is intentional
for TAP protocol compatibility:

- Gateway expects 200 OK with wrapped IndexerResponsePayload format
- GraphQL errors are conveyed in the response body, not HTTP status
- Maintains compatibility with TAP payment flow

This clarifies the design decision that auditors flagged as potentially
problematic (TRST-L-8), confirming it is intentional behavior.

Addresses: TRST-L-8

Fix silent allocation identifier downgrade that caused V2 (Horizon)
receipts to be incorrectly routed to V1 (Legacy) sender allocation
actors when collection_id parsing failed.

Previously, if CollectionId::from_str failed (e.g., for 20-byte addresses
during migration), the code fell back to AllocationId::Legacy, misrouting
the receipt. Now:

- If collection_id is a 20-byte address (40 hex chars), convert it to
  CollectionId using the standard left-padding conversion
- All V2 receipts stay on the Horizon path, never downgrade to Legacy
- Fallback uses zero CollectionId but maintains Horizon routing

This is consistent with get_pending_sender_allocation_id_v2() which
already handles the 20-byte address migration case correctly.

Addresses: TRST-L-9

…us endpoint (TRST-L-10)

The /status endpoint was forwarding responses from graph-node without
validation, which could cause client panics when graph-node returned
empty or malformed JSON responses.

Changes:
- Add validation to reject empty response bodies with BAD_GATEWAY error
- Validate response is valid JSON before forwarding to clients
- Add tests for empty and invalid JSON response handling

…TRST-L-11)

Metrics with allocation-level labels ([sender, allocation]) were not
being cleaned up when SenderAccount or SenderAllocation actors shut down,
causing stale gauge values and unbounded label cardinality growth.

Changes:
- Add PENDING_RAV cleanup in ActorTerminated handler (was missing despite
  other allocation metrics being cleaned there)
- Add allocation-level metrics cleanup in post_stop for all tracked
  allocations (UNAGGREGATED_FEES, UNAGGREGATED_FEES_BY_VERSION,
  INVALID_RECEIPT_FEES, PENDING_RAV)
- Clean up PENDING_RAV for allocations in rav_tracker (closed allocations
  with pending RAVs not in allocation_ids)

Note: ALLOCATION_RECONCILIATION_RUNS counter is intentionally not cleaned
as removing counter labels can cause rate() calculation issues.