Hardening: serve untrusted /app/* on a separate origin from /admin (same-origin risk)

[milkway]

Documented in docs/SECURITY.md, tracked here so it isn't lost: apps under /app/* are same-origin with /admin/*, so compromised app JS can issue authenticated POSTs to the admin (the Fetch-Metadata/Origin CSRF guard helps, but same-origin requests are the hard case). This makes the Disk-panel backstops (#871) mandatory.

Direction (low priority / deployment guidance)

• For not-fully-trusted apps, document/support serving the portal+admin on a separate host/origin from the app subdomain.
• Consider an option to mount /app/* under a distinct origin.

[milkway]

Opção A entregue (PR #900). docs/SECURITY.md ganhou a §6.1 Hosting untrusted apps (same-origin): o risco, por que nginx sozinho não separa as origens (Ruscker é path-based e emite links/base-href relativos à origem do request), o que funciona hoje (instância separada / higiene operacional / backstops #871/#889/#894 limitando o raio), e uma não-meta no threat model. Apps first-party numa origem só seguem sendo a postura suportada (cast/box/hugo).

Issue mantida aberta como tracker da Opção B (origem de app de primeira classe). Pré-requisitos do design, do comparativo:

• rotear /app/* por Host (não por caminho) e emitir URLs absolutas da origem do app (rewriter lol_html/base-href + cards do portal);
• interagir com context-path/--base-path (cast /box, hugo /ruscker);
• respeitar o gate de forwarded-headers (§7, fix(proxy,sessions): XFF/XFP trust, at_capacity, hot-path write, sweep race, latent footguns (#744) #762) no roteamento por Host;
• escopo de cookie por-spec (__ruscker_session_{spec}) e do cookie de sessão admin por host;
• DNS + TLS (wildcard p/ subdomínio-por-app) — pesado em ambiente gov/rede travada.

Só se justifica quando aparecer cenário multi-tenant / apps de terceiros não-confiáveis — hoje não é o caso.