# TASK 2.1: Add backend customer and tenant membership persistence

## Summary

Add the backend persistence model that replaces Laravel-owned `Customer` storage and supports identity-backed tenant authorization.

## Dependencies

- TASK 1.2 complete

## Files to Modify

### 1. Backend entities and EF mapping

Likely files:

- `backend/Kds.Ai.Data/KdsAiDbContext.cs`
- new entity files under `backend/Kds.Ai.Data/Entities`
- new EF configuration files if this project uses them
- new EF migrations under `backend/Kds.Ai.Data/Migrations`

### 2. Backend data access and DI

Likely files:

- `backend/Kds.Ai.Data/DependencyInjectionExtensions.cs`
- new repositories or services for customer and membership access

## Required Behavior

The backend must persist:

- customers/tenants formerly owned by Laravel,
- stable tenant identifier used by application data,
- any membership or linkage needed to map an authenticated Keycloak subject to the correct customer/tenant,
- enough customer metadata to satisfy existing admin and portal use cases.

The model should support:

- listing customers,
- creating and updating customers,
- resolving caller tenant membership,
- enforcing tenant scoping for non-admin users.

## Acceptance Criteria

- [ ] Backend has a customer/tenant entity model
- [ ] Backend has a membership or equivalent identity-link model if required by chosen auth design
- [ ] EF migration exists for the new persistence model
- [ ] DI wiring exists for customer and membership access
- [ ] The design does not depend on Laravel database records

## Notes

- Keep ownership boundaries clear: customer data belongs here, not in Keycloak.
- Avoid recreating a full local identity store unless there is a concrete app-only need.