Add pagination and truncation detection to related

[artpar]

Summary

daptin-cli related has no --page, --page-size, or --all option and discards JSON:API pagination metadata. Daptin v0.12.29's relation handler uses DbResource.FindAll, which silently injects page[size]=1000 when the caller supplies no page size. A successful CLI result containing 1,000 relationship rows is therefore ambiguous and cannot support a complete preservation or authorization inventory.

This matters because daptin-cli v0.8.5 intentionally rejects generated join-table names and correctly directs operators to the owning entity plus relation commands. related is therefore the canonical read path for association reference ids and association permissions, but it cannot currently prove completeness above the implicit page boundary.

Versions and environment

• daptin-cli: v0.8.5, source commit 42109527e6af32ab7b7fa71f7894e4041e974943
• Daptin: v0.12.29, source commit 7880d086c46f879fe015ca44080dd86d3c71a836
• Database: PostgreSQL 16
• Client: macOS Darwin amd64

Reproduction

Against an explicit authenticated non-production context, create one disposable normal account and associate it with eleven disposable usergroups, then run:

daptin-cli --config context.yaml --output json related user_account <account-ref> usergroup_id --columns reference_id,permission,relation_reference_id
daptin-cli --config context.yaml --output json related user_account <account-ref> usergroup_id --page-size 100

The first command returned all twelve rows in this small setup (the eleven test relations plus the account's existing users-group relation). The second exits nonzero because --page-size is unsupported.

Source confirms the latent truncation boundary:

• cmd/crud.go calls FindRelated(..., nil) and exposes only --columns.
• client/relation.go builds /api/<entity>/<ref>/<relation> without query parameters and parses only data.
• Daptin v0.12.29 DbResource.FindAll injects page[size]=1000 when absent.

The CLI cannot distinguish exactly 1,000 rows from a truncated result and cannot request the next page. Listing the generated join table is not an alternative: v0.8.5 deliberately rejects generated join-table names and instructs callers to use relation commands.

All disposable reproduction rows were removed and exact absence was read back through the CLI.

Expected behavior

Please add bounded pagination to related, consistent with list, for example:

daptin-cli --config context.yaml --output json related user_account <ref> usergroup_id --page-size 100 --page 2 --columns reference_id,permission,relation_reference_id
daptin-cli --config context.yaml --output json related user_account <ref> usergroup_id --all --max-pages 100

Exact flag names are not important. The command should:

• forward explicit JSON:API page number/size parameters;
• preserve association reference_id, permission, and relation_reference_id projections;
• expose enough pagination metadata to detect whether another page exists, or provide a bounded --all mode that fails when its maximum is exceeded;
• render an empty JSON result as [] under --output json;
• return nonzero for malformed/truncated pagination rather than silently claiming completeness;
• keep every request bound to the explicit CLI context.

Acceptance test

With 1,005 associations on one source row:

1. --page-size 100 --page 1 returns exactly the first 100 association rows;
2. page 11 returns the final five rows;
3. bounded --all returns exactly 1,005 unique association reference ids and permissions;
4. a lower page limit exits nonzero and reports truncation without printing row contents;
5. zero associations with --output json returns [].