Relationships: one-to-one (constrained foreign key)

[jkalias]

Sub-issue of #3. Builds on the FK plumbing from the many-to-one / one-to-many sub-issue.

Scope

Support a one-to-one association (e.g. Person ↔ Passport): a foreign-key reference constrained so at most one row on each side participates.

Design

• Reuse the relationship metadata, PRAGMA foreign_keys = ON, and table-ordering introduced in the many-to-one sub-issue.
• Declaration: a dedicated macro to distinguish it from many-to-one, e.g. MEMBER_UNIQUE_REFERENCE(Passport, passport), or a modifier on MEMBER_REFERENCE. The deciding factor versus many-to-one is a UNIQUE constraint on the FK column.
• Schema: passport_id INTEGER UNIQUE REFERENCES Passport(id). The UNIQUE constraint is what enforces the "at most one" cardinality and is the only schema difference from many-to-one.
• Decide which side holds the FK (the optional/owning side) and document it. A truly symmetric 1↔1 only needs the column on one side.

Fetching

Same explicit/lazy model as the many-to-one sub-issue, but the inverse resolves to a single record rather than a collection — db.FetchReferenced<Passport>(person.passport_id) and a single-result inverse lookup.

Acceptance criteria

• One-to-one macro emits a UNIQUE FK column with enforcement on.
• Inserting a second row that reuses an existing referenced id fails the UNIQUE constraint (test included).
• Save/fetch round-trips both directions, inverse returns a single record.
• README "Relationships" section extended with the one-to-one form.

Out of scope

Many-to-many.