Access requests for — model as a change-request type?

[unidoc-ahall]

A customer needs access requests that get approved via a flow like change requests.

Proposal: add a type field to change requests (change | access_request) sharing the same approval flow. Creating an access request = flipping the type (one
toggle) — not the crufty ticketing path we're replacing.

Why this over the alternatives:

• vs a separate entity: doubles the approval flow + more UI/CLI/API surface, for the same lifecycle.
• vs a description-hack: no governance, not searchable, no reporting.
• One self-hosted flow fits the "one platform, many standards" positioning.

The specifics (which system, who, how long) go in the existing notes/description — no new structured fields. Adding access-request-only fields would just bloat the entity
for no real gain.

[unidoc-ahall]

Decision taken → tracked in #137. Change-request type stays TEXT with a DB CHECK ('change' | 'access_request'), editable via API/UI/CLI, and extensible by adding a value to the CHECK + db.ChangeTypes. Access-request specifics live in the notes — no bespoke structured fields. Implementation in the linked PR.