feat: isolate apartment portfolios by landlord (#25)

docs/adr/0001-multi-tenant-preparedness.md

@@ -1,5 +1,5 @@
 # Preparedness for Future Multi-Tenancy
 
-**Status**: accepted
+**Status**: superseded by ADR-0013
 
 The application will initially be deployed as a single-portfolio (single-tenant) system where all users share a common property portfolio. However, to prevent schema lock-in and enable an easy transition to a multi-landlord SaaS platform in the future, we have decided to introduce a `Bailleur` (Landlord) entity. All assets, leases, and loans will be partitioned by `BailleurId`, with a single default `Bailleur` instance created at setup.

docs/adr/0010-link-landlord-profiles-to-oidc-subjects.md

@@ -1,6 +1,6 @@
 # Link Landlord Profiles to OIDC Subjects
 
-**Status**: accepted
+**Status**: superseded by ADR-0013
 
 ## Context
 

docs/adr/0011-rental-aggregate-boundaries.md

@@ -0,0 +1,5 @@
+# Keep rental aggregates small
+
+**Status**: accepted
+
+Within Rental Management, `Lease` owns its contractual lifecycle, dates, rent terms, and lease-party relationships while referencing independent `Apartment` and `Tenant` aggregates by ID. Activation freezes the landlord identity and address, apartment address, tenant identities and addresses, guarantors, and financial terms; later changes are effective-dated immutable `LeaseAmendment` records that preserve both contract versions and may only recalculate future unpaid dues. `RentDue` and `RentPayment` are independent aggregates; a positive payment owns allocations whose sum cannot exceed the amount received, each allocation cannot exceed its due's remaining balance, and one payment may cover multiple dues only within the same lease. Any surplus stays unallocated. `Guarantor` remains internal to `Lease` until it gains an independent lifecycle or must be shared across leases.

docs/adr/0012-pragmatic-domain-architecture.md

@@ -0,0 +1,5 @@
+# Use pragmatic domain architecture in a modular monolith
+
+**Status**: accepted
+
+Refactor the current backend as one Rental Management bounded context organized by domain capability, with business invariants enforced by aggregate behavior and thin HTTP/application orchestration. Keep Spring Data annotations on domain objects and avoid separate persistence models, ports, adapters, asynchronous events, or deployable services until a real boundary requires them; the future LMNP Tax and Accounting Core Domain will be a separate context consuming rental facts.

docs/adr/0013-isolate-portfolios-by-landlord.md

@@ -0,0 +1,5 @@
+# Isolate portfolios by landlord
+
+**Status**: accepted
+
+Each OIDC subject identifies one `Landlord`, and that landlord exclusively owns its apartments, leases, rent dues, payments, attachments, and generated documents. Every protected query and command is scoped and authorized by the authenticated landlord; the shared default portfolio is removed so contractual snapshots always identify one unambiguous landlord. This supersedes ADR-0001 and ADR-0010; multi-user portfolio membership remains deferred until it is required.