Themes were never applying: fix the selector's specificity

Every theme set so far validated, stored, was served in the profile response,
and did nothing at all to the page.

applyTheme wrote its rule as `[data-profile="alice"]`, specificity (0,1,0). Pico
sets its palette on `:root:not([data-theme=dark])`, which is (0,2,0) — `:not()`
contributes the weight of its argument. Source order never came into it; the
theme lost on specificity and would have lost from anywhere in the document. The
comment in index.html asserted the opposite in as many words:

    landing last is all it needs to win: no user rule ever has to
    out-specify anything

The rule is now `:root[data-profile="alice"]`, which matches Pico's (0,2,0) and
wins on being last, and both the comment and docs/profile-template.md now explain
the arithmetic rather than assert the conclusion.

Worth naming how this survived: it failed silently in every direction. The
whitelist accepted the declarations, the canonical text round-tripped through
SQLite, the profile response carried them, applyTheme built the block and put it
in the document — and the page rendered exactly as if none of it existed. Every
test passed because every test asked whether the theme was *stored* correctly.
Nothing read a computed style out of a real browser, which is the only place the
question "did this change anything?" can actually be answered.

Also: .state now takes --pico-muted-color. Where a link goes and how a service is
shared are both secondary to the name, and were being drawn at full strength.

commit

8f35b413c930888152a3973a8d2c6372d289a1d9

parent

1a02e9fa0aa7f5ad9fa84984c3bfeaa56de0f761

author

Dami <dami.etoile@gmail.com>