Gate every relationship path on exposeRelationships

[evoactivity]

Closes #10.

The problem

isRelationExposed is documented as the single home for the relation-visibility rule, shared by serialization and ?include= validation. Two write paths never went through it:

• The relationship endpoints resolve relations through getRelationOrFail, which honoured serializeAs: null and ignored exposeRelationships. Registering a relationships controller quietly reopened a hidden relation, for reads and writes, on all five routes.
• The deserializer had its own inline serializeAs check, so a POST or PATCH body with a relationships member naming a hidden relation was accepted.

The fix

getRelationOrFail takes the registry and applies isRelationExposed. The parameter is required rather than optional, so a new call site cannot skip the check, which is how the drift happened in the first place. The function is internal, so the signature change is not a public API change. The deserializer consults the same rule for relationship members, replacing its inline check.

The relation name is resolved before the exposure check, so a kebab URL segment is checked under its Lucid name rather than its URL form.

Hidden means indistinguishable from nonexistent

On every path, a hidden relation behaves exactly like one that was never defined. The endpoints return 404, where the name is a URL segment. Write bodies get the unknown-member 400. A 403 would confirm the relation exists, which is the thing being hidden.

Behaviour change

Anyone using exposeRelationships together with a relationships controller loses routes that were reachable by mistake. Worth a minor bump rather than a patch.

Tests

16 new tests in tests/unit/relationship_endpoint_exposure.spec.ts, written red first: all five relationship routes reject a hidden relation, hidden and unknown are indistinguishable on both status and title, and the guards, exposed relations still serve, resources without exposeRelationships keep every relation, unregistered models are unaffected. The to-many write tests use a manyToMany relation deliberately, since hasMany rejects replace and remove with 403 regardless and would mask the gate.

Unit suite 128 passed, example app functional suite 52 passed, lint and typecheck clean.

Also adds a .prettierignore for pnpm-lock.yaml and CHANGELOG.md in a separate commit, so pnpm format stops burying real changes in reformatting noise.