Runtime vykonava strom, prokliky z widgetu, oprava ukladani rozlozeni

Runtime: `src/runtime/executor.ts` jde krok po kroku, u podminky se vetvi,
do poli dosadi parametry, akci pusti pres runScript a vystupy pripise do
kontextu pro dalsi krok. Cely prubeh jde do logu ticketu vcetne toho, co
sluzba vratila. Pouzivaji ho obe cesty: akce na ticketu i webhook.

Opraveno: rozlozeni dashboardu s vlastnim widgetem se NEDALO ULOZIT.
`validateLayout` znala jen vestaveny katalog, takze kazdy pokus skoncil
hlaskou "widget v katalogu neexistuje" - presne to, co hlasil uzivatel.
Katalog je ted jedna funkce a pouziva ji nabidka i kontrola. Zaroven je
za konkretni firmu, driv slo polozit dlazdici jedne firmy na dashboard druhe.

Prokliky: z widgetu lidi na cloveka, ze seskupeni na vyfiltrovany seznam
ticketu. Odkazy sklada server, protoze on jediny zna filtr widgetu. Seznam
ticketu cte filtr z adresy a umi filtrovat na typ, tag a skupinu.

Tabulky: spolecna `TicketTable` pro seznam i detail osoby. Na mobilu se
neposouva do strany, uzka obrazovka dostane karty. Detail osoby ma velkou
tabulku se zalozkami "ma u sebe" a "vyresil" a prepinacem pohledu.

Odebrano: simulace vcetne tlacitka, dialogu i endpointu. Trojice pohledu
nad tickety - vyber firmy je select, "moje" je prepinac, driv to delalo
totez dvakrat.

Pridan zmereny rozbor kapacity pro 200 firem (19-kapacita-200-firem.md):
soucasny stav to nezvladne, protoze data jsou v pameti a vypis je linearni.
Zmereno na 5 000 ticketech, vcetne toho, co s tim a kolik serveru to chce.

Overeno 7 kontrolami proti bezicimu serveru.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

documentation/04-api.md

@@ -80,7 +80,6 @@ Vyzaduji `Authorization: Bearer <token>`:
 | POST   | `/api/admin/impersonate/stop`                       |
 | GET    | `/api/admin/impersonate/candidates`                 |
 | GET    | `/api/admin/audit`                                  |
-| POST   | `/api/simulate`                                     |
 
 Sprava zaznamu ma u kazde entity stejnou petici (seznam, detail, vytvoreni,
 uprava, mazani) na `/api/dashboard/settings/<entita>`, protoze ji dela jedna
@@ -246,21 +245,6 @@ s 403. Kazde prepnuti i ukonceni je v auditu vcetne toho, kdo to byl doopravdy.
 
 Svuj puvodni token si klient odklada do `sessionStorage`, server o nem nic nevi.
 
-## Simulace
-
-`POST /api/simulate` vyvola provozni udalost pro nahled ziveho dashboardu.
-Zamerne meni skutecna data, ne jen posila falesnou notifikaci.
-
-Akce: `ticket.created`, `ticket.resolved`, `incident.started`,
-`incident.resolved`, `automation.run`.
-
-U `ticket.created` urcuje `channel` (whatsapp, facebook, instagram, email, voice,
-form, portal), odkud pozadavek prisel, a podle toho se poskladá i log ticketu. `knownCustomer: false` znamena, ze CRM firmu nedohleda -
-ticket zustane bez zakaznika i bez resitele a v logu je videt proc.
-
-Nevyplnena pole server doplni ukazkovou hodnotou. U akci s "resolved" se bez
-zadaneho id pouzije prvni nevyrizeny zaznam.
-
 ## Sluzby a konektory
 
 Popis modelu je v [12-sluzby-a-konektory.md](12-sluzby-a-konektory.md), tady jen API.