web UI renders with no styling at all, and KB articles have no detail page

[TbusOS]

Two defects that compound: the web UI renders with no styling at all, and a KB
article cannot be opened. Together they make the Knowledge Base section of the
UI unusable for reading.

1. Every page renders unstyled

All styling is a single inline <style> block emitted by layout(). The
response carries Content-Security-Policy: default-src 'self', and that policy
drops inline styles unless they are permitted by 'unsafe-inline' or matched by
a nonce/hash. So the browser discards the entire stylesheet and falls back to
its own defaults — serif body text, blue underlined links, no sidebar layout.

Measured with the same HTML served three ways:

CSP header	body background	CSS rules applied	sidebar width
default-src 'self' (shipped)	transparent	0	1184px (layout gone)
+ style-src 'self' 'unsafe-inline'	rgb(250,249,245)	36	220px
no CSP header	rgb(250,249,245)	36	220px

The identical document opened over file:// always renders correctly, which is
why this does not show up until a browser talks to the server. Nothing is wrong
with the markup or the CSS — a hardening header is discarding it.

2. KB articles have no detail page

/kb lists articles, but:

• the titles are not links,
• no /kb/<topic> route is registered (/memory/ has its detail counterpart,
  /kb/ does not),

so a reader sees one summary row and can go no further — the chapter text is
unreachable from the UI. docs/design/kb-article.html specifies this page
(source/digest tabs, chapter table of contents, metadata panel), and TASKS.md
lists T-119 "KB Article page (read only)" as done.

Suggested direction

1. Per-response nonce, not 'unsafe-inline'. Allowing arbitrary inline
   styles would fix the symptom while admitting any injected style, which is
   what the header exists to prevent. A fresh nonce per response matches exactly
   the one block the server emitted.
2. /kb/<topic> detail route plus a small stdlib Markdown renderer — the
   project keeps its core dependency-free, and render.py currently exposes
   only card / esc / layout / table, none of which can render chapter prose.

Both the topic in the URL and the chapters: entries in README.md are
author-controlled input and need to stay confined to the article directory.

I have a working implementation of both and will open a PR.