#668 serve-auth: Group aggregate + built-in model

Parent

Sub-issue of #662 (serve authentication & authorization). Layer 1, item 2.

Summary

Implement the Group aggregate and built-in model for the domain/access/ bounded context. Groups are locally-managed named sets of principals, used as grant subjects alongside individual users and IdP-asserted groups (collectives).

What to build

A Group aggregate root as a built-in model following the enrollment-token / worker / step-lease precedent:

Group schema

• name — unique group identifier
• members — array of principal references (user:<sub>)
• createdBy — principal who created the group
• createdAt — timestamp

Model methods

• create — create a new named group
• add-member — add a principal to the group
• remove-member — remove a principal from the group
• list — list all groups
• members — list members of a specific group

Key invariants

• Groups are locally-managed — membership is stored in the model. This is distinct from IdP-asserted groups (idp-group:<name>) whose membership comes from the provider's userinfo response and is never stored locally. The two must not be confused.
• Generic data writes must not be able to create or alter group records — the built-in model owns its data as model-method (the existing OwnershipValidationError pattern)
• Groups are referenced in grants as group:<name>. The AccessDecisionService (layer 1, item 4) will resolve group membership when evaluating grants — this model just stores the data.

Scope

• Pure domain code — no enforcement wiring, no CLI commands
• No dependency on OAuth, TLS, or other auth machinery
• Fully testable in isolation
• Does NOT handle IdP-asserted groups — those are resolved from the principal's claims snapshot at decision time (item 4)

References

• Enrollment token model for the built-in model pattern: src/domain/models/worker/enrollment_token_model.ts
• Worker model: src/domain/models/worker/worker_model.ts
• Grant model (sibling issue): #667