Design Pydantic v2 models that validate a real domain, not just shapes

Design Pydantic v2 models for the domain below. The goal is models that reject bad data at the boundary, not models that just describe field names and types and hope validation happens somewhere else.

DOMAIN
A booking for a rental property, plus the guest making it

BUSINESS RULES TO ENFORCE
check-out date must be after check-in date; a booking under 2 nights requires a minimum-stay override flag

CROSS-MODEL RULE
number of guests can't exceed the property's max_occupancy, which lives on a separate Property record

REQUIREMENTS
1. Use Pydantic v2 syntax specifically: model_config = ConfigDict(...), not the v1-style class Config. Use Field(...) constraints (gt, max_length, pattern, etc.) for anything checkable declaratively, before reaching for a custom validator.
2. Use @field_validator for single-field logic that Field() can't express, and @model_validator(mode="after") for anything depending on more than one field within the same model (e.g. end_date must be after start_date). Name which business rule each validator enforces, in a comment.
3. If number of guests can't exceed the property's max_occupancy, which lives on a separate Property record depends on data outside this one model — a lookup against another record, like guest_count against a property's max_occupancy stored elsewhere — say explicitly that this cannot be a Pydantic validator alone and belongs at the service layer, rather than silently faking it or silently dropping it.
4. Be deliberate about Optional versus required — a field should only be optional if the domain genuinely allows it to be absent, not because it's convenient during construction. Justify each optional field in one line.
5. Use Annotated[...] types for any constraint you'd otherwise repeat across multiple models, instead of copy-pasting the same Field(...) arguments everywhere.
6. Serialization: API is camelCase JSON (checkInDate), Python code should stay snake_case. If any field needs a different name on the wire than in Python, use alias or an AliasGenerator and set populate_by_name correctly, rather than manually renaming keys after the fact.
7. Give every model a docstring stating what real-world entity it represents and what invalid state it's specifically guarding against.
8. Every raised ValueError inside a validator must produce a message that names the actual rule violated and, where useful, the offending value — a validator that just raises ValueError("invalid") forces the caller to re-derive which of several possible rules actually failed, defeating the point of having named, separate business rules in the first place.
9. If a field represents money, a quantity with units, or anything else where a plain float or int silently permits a nonsensical value (a negative price, a fractional item count where only whole units make sense), constrain it precisely with Field(...) rather than a bare numeric type that happens to also accept the invalid range.

OUTPUT FORMAT
1. The models, in dependency order.
2. A table: business rule, and which model, validator, or "service layer, not Pydantic" enforces it.
3. One example payload that should raise ValidationError, and what the error tells the caller.
4. Confirmation that every validator's error message names the specific rule it enforces, not a generic "invalid" string.