feat(patients): clinic-side patient registry

Clinics get a real patient ledger. Labs see only patientCode — no name,
phone, date of birth, or notes ever cross the team boundary.

Data model
  - New table 'patients' (clinicTenantId, patientCode, firstName, lastName,
    phone?, dateOfBirth?, notes?, archived). Unique index on
    (clinicTenantId, patientCode) so each clinic gets its own code space.
    Fulltext index on (firstName, lastName) for future patient search.
    Row permissions Role.team(clinicTenantId) only — labs literally cannot
    read the rows.
  - jobs.patientId attribute (optional) + key index, references the
    patient row when one exists. patientCode stays denormalised on jobs so
    labs keep a stable identifier without joining patients.

Server
  - createPatientAction: clinic-only, requireTenantKind guard. Protocol no
    is optional; if absent we generate a 6-char unique code (re-roll on
    collision, 8 attempts). Duplicate protocol no within a clinic is
    rejected with a friendly error.
  - updatePatientAction: edits name/phone/dob/notes. patientCode is
    explicitly NOT mutable — re-keying historical jobs would be confusing.
  - archivePatientAction: toggle, preserves history.
  - listPatients / getPatient queries return plain objects via toPlain.

UI
  - /patients page (clinic-only, sidebar nav 'Hastalar', middleware
    protected): table + add form + edit dialog + archive.
  - /jobs/new: patient Select replaces the bare patientCode input. Picking
    a patient locks the patientCode field to that patient's code; falling
    back to 'Hasta listesinde yok — kodu manuel gir' keeps the old free-
    text flow.
  - createJobAction validates patientId ownership and overwrites
    patientCode with the patient's code on the server, so a manipulated
    form can't desync the two.
  - /jobs/[jobId] (clinic side only): adds a 'Hasta Bilgileri' card with
    name/phone/dob/notes and uses the patient's full name as the page
    title. Lab side is unchanged — code only.

The protocol-no / generated-code split matches what the user asked for:
existing patient management software's protocol number flows in directly,
otherwise the system mints one.

src/lib/validation/job.ts

@@ -11,6 +11,11 @@ const PROSTHETIC_TYPES = [
 
 export const createJobSchema = z.object({
   labTenantId: z.string().min(1, "Laboratuvar seçin."),
+  patientId: z
+    .string()
+    .trim()
+    .optional()
+    .transform((v) => (v ? v : undefined)),
   patientCode: z.string().trim().min(1, "Hasta kodu zorunlu.").max(50),
   prostheticType: z.enum(PROSTHETIC_TYPES, { message: "Protez türü seçin." }),
   memberCount: z

src/lib/validation/patient.ts

@@ -0,0 +1,31 @@
+import { z } from "zod";
+
+export const patientSchema = z.object({
+  patientCode: z
+    .string()
+    .trim()
+    .max(50)
+    .optional()
+    .transform((v) => (v ? v.toUpperCase() : undefined)),
+  firstName: z.string().trim().min(1, "Ad zorunlu.").max(100),
+  lastName: z.string().trim().min(1, "Soyad zorunlu.").max(100),
+  phone: z
+    .string()
+    .trim()
+    .max(30)
+    .optional()
+    .transform((v) => (v ? v : undefined)),
+  dateOfBirth: z
+    .string()
+    .trim()
+    .optional()
+    .transform((v) => (v ? new Date(v).toISOString() : undefined)),
+  notes: z
+    .string()
+    .trim()
+    .max(2000)
+    .optional()
+    .transform((v) => (v ? v : undefined)),
+});
+
+export type PatientInput = z.infer<typeof patientSchema>;