# Bounded list import response

`POST /api/v1/lists/:id/entries?return=summary` opts into a bounded response:

```json
{"count":100000,"content_hash":"sha256:...","changed":true}
```

`count` is the total stored effective CIDR count after publication. `content_hash` is the stored content hash; `changed` records whether the root list's effective memberships changed. The response is derived from a SQL count and hash projection and does not serialize stored rows, source config or full list detail.

The opt-in path accepts a fully duplicate valid import as a successful no-op with `changed:false`, preserving agent generations. Mixed valid/invalid input still rejects the entire request before publication. With no query parameter the existing full-detail success response and duplicate-import error behavior remain unchanged. The existing 100000-entry and 8 MiB import bounds apply to both modes.

The frontend import/delete mutations use summary responses and invalidate list queries. `DELETE /lists/:id/entries?return=summary` returns the same summary after atomic deletion. Default delete responses remain full details.

`GET /lists/:id?view=page&limit=100&offset=0` opts into SQL pagination (limit 1–200, offset 0–10000000). Without query parameters the legacy full detail remains available. Invalid paging/filter parameters reject the request instead of falling back to the full response. Paged responses contain metadata, bounded `items` and preview `entries`, total stored `entry_count`, filtered logical-item `total`, `limit` and `offset`. `config_json` is `{}`; raw source config is not returned. Each item contains the true `resolved_count`, at most three `resolved_cidrs` previews and `resolved_truncated`.

Optional `q` searches value/name and kind. `filters` is JSON for at most ten filters: `{field:'value'|'kind',operator,values:string[]}`. Operators match the frontend's `is`, `is_not`, `is_any_of`, `is_not_any_of`, `contains`, `not_contains`, `starts_with`, `ends_with`, `empty` and `not_empty`. Filters combine with AND, values with OR. Filtering occurs over the entire list before pagination; nested-list value text includes its child name and ID. The deterministic SQLite `evofw_lower` function preserves JavaScript Unicode case folding for names.

Manual source items are projected through SQLite JSON1 and external CIDRs through `ip_list_entries`; full rows/config/resolution arrays are not materialized in JavaScript before slicing. `GET /lists?view=summary` also excludes source config from the metadata catalog query. Defaults for both endpoints preserve legacy behavior.

Observed Windows/in-memory endpoint test: 100000 unique IPv4 inputs returned 120 response bytes in approximately 1363 ms. A 200-item page from that list returned 31048 bytes; an exact filter for the 100000th item returned 524 bytes. These are local samples, not production or two-CPU capacity claims. Tests also cover full duplicate no-op without generation bumps, invalid mixed input preserving count/hash/revision, default legacy detail shape, bad paging/filter parameters, external-prefix pagination, bounded nested-list resolution previews and Unicode child-name filtering.