1.1.0 — what has actually met a Populi server

No code changed. This release exists because the previous one claimed coverage the evidence did not support.

Most of the surface that shipped in 1.0.0 as contract-only has now been driven against a live instance. The routes behaved as written — but two undocumented behaviours turned up that callers need.

Documented, each measured rather than inferred

• A course enrollment's student_id is a PERSON id. A row reporting student_id: 24564256 resolves at GET /people/24564256; by_student_id(24564256) finds nobody. The rows carry no person_id key at all, so the only identifier present is named after the scheme it does not belong to. Correct for the grade routes, wrong for anything resolving a visible student id — and wrong silently.
• An honoured expand can still be null. expand: ["student"] adds the key to every /people row and sets it null for non-students. That is a different thing from the key being absent because the expand was dropped, and only checking for the key separates them. It also defeats row.get('student', {}).get(...), which still raises.
• people.with_role() walks every page. On a role the size of Student that is thousands of people against a budget shared with everything else using the key.

Verified live
academic_terms, courses (offerings/assignments/enrollments), data_slicer, files.download_link, people.online_payment_link, people.list with expands, custom_fields.definitions_for_scope and definition() including the options expand, and PopuliFilter — the last confirmed by partition: a negated condition and its positive returned 2,843 and 27,596 against a directory of 30,439, which a dropped filter cannot produce.

Still unproven, marked ○ in the README: grade writes, file upload, term-scoped writes, people.update, by_student_ids. Every one is a write or a bulk walk.