List Skills

One page of the skills visible to the caller. Postgres only — no S3 reads.

Paginated from the start rather than added later: the visibility filter also matches every tenant-wide skill, so this response grows with the tenant's shared library, and changing the envelope once clients depend on it is a breaking change.

page/size are not declared here on purpose — add_pagination(app) (main.py) supplies them, so this endpoint inherits the same defaults and ceilings as every other paginated route instead of hard-coding its own. The LIMIT/OFFSET and the COUNT run in SQL; _summary is applied to the page rows only.

Both filters exist because the client cannot do them correctly. Narrowing a page is not narrowing the set: the Skills page's scope tabs filtered the 50 rows they had been handed, so a tab could report "no skills" while matching skills sat on page 2. Anything a paginated list is filtered by has to be filtered in SQL.

datamate_id answers "what does this workspace have?", which nothing could ask before — attachments were only readable from the skill's side, on the detail response, one request and one S3 read at a time.

Note the two filters are asymmetric on purpose. privacy needs no authorization: it only ever narrows what the visibility filter already allows. datamate_id names another object, so the workspace is checked first — see below.