A personality belongs to a person

Owner's correction to 1.4.0: a model's character is per (model, person), and only
the description and the notes stay instance-wide. Two people talking to one model
are not talking to the same personality, and neither can see the other's.

The administrator's box becomes the DEFAULT, resolved by `personas.effective` as
a fallback and never as a layer -- two personalities at once contradict each
other with nothing to say which is losing, which is the reasoning behind "system
prompts replace, never stack". `persona_write` takes no argument naming a model
or a person; both come from the ToolContext, so it can only write the character
it has with whoever it is talking to, and it never touches the default.

Impressions move to their own table. Not a `kind` column: 1.4.0 shipped
`UNIQUE(model_key, owner_id)`, SQLite cannot alter a constraint and this schema
is additive-only, so a discriminator would leave an upgraded instance unable to
hold both rows for one pair. That leaves the first MANUAL_STEPS entry this
project has had -- the two shapes are indistinguishable, so nothing rewrites
them: a repair would be guessing at text that is read back in the first person.

TWO BUGS FROM A PHONE

`min-width` beats both `width` and `max-width` -- CSS clamps width to max-width
and then raises the result to min-width -- so `.canvas` and `.terminal` were
384px wide on every screen narrower than that, their `min(…, 100vw)` cap
overruled, and `.inspector` had no cap at all on a width that is a preference
draggable to 2400px. None of it scrolled sideways, because all three are
`position: fixed` and fixed overflow does not extend the scrollable area -- which
is exactly why the 1.1.0 narrow pass reported these pages clean. `min-width: 0`
in the overlay query, full width below the phone breakpoint, tablet column kept.

And the install button now says why it is absent. Measured against the live
instance: the manifest meets every Chrome criterion and the blocker is a
certificate from a private CA, so the origin is not trustworthy, the service
worker is refused and no install is offered. `base.html` had been swallowing that
with an empty catch -- which kept the page working, the reason it was there, and
threw away the only evidence. It now records the outcome and `app.js` turns it
into a sentence naming the certificate, which is the cause the old hint did not
mention.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/lembas/web/templates/admin/model_detail.html

@@ -362,17 +362,26 @@
 {# Outside the form above, and it has to be: two forms cannot nest, and this one
    posts somewhere else. See the note beside the Detect button. #}
 <section class="card">
-  <h2 class="card__title">Personality</h2>
+  <h2 class="card__title">Default personality</h2>
   <p class="card__lede">
-    Who this model is, carried into every conversation rather than given to it for
-    one. Different from the system prompt above: that is an instruction you write,
-    this is a character it can be — and, with
-    <strong>Edit its own personality</strong> ticked, one it can rewrite itself.
-    Every version is kept below.
+    Who this model is before it has worked out who it is with somebody. Different
+    from the system prompt above: that is an instruction you write, this is a
+    character it can be — and, with <strong>Edit its own personality</strong>
+    ticked, one it rewrites for itself.
+  </p>
+  <p class="card__lede">
+    <strong>A personality belongs to a person.</strong> Each account gets its own
+    version of this model's character, starting from what you write here and
+    diverging from it the first time the model writes its own. Changing this
+    afterwards does not reach anybody who already has one, and it is not stacked
+    underneath theirs — two personalities at once would contradict each other and
+    nobody could tell which was losing. What the model *is*, as opposed to who it
+    has become with somebody, belongs in <strong>Description</strong> and
+    <strong>Facts for other models</strong> above, which are the same for everyone.
   </p>
   <form method="post" action="/admin/models/{{ model.id }}/persona">
     <div class="field">
-      <label class="field__label visually-hidden" for="persona">Personality</label>
+      <label class="field__label visually-hidden" for="persona">Default personality</label>
       <textarea class="textarea" id="persona" name="content" rows="6"
                 placeholder="Nothing yet. Write one, or let the model write its own."
       >{{ persona.content if persona else "" }}</textarea>
@@ -396,11 +405,12 @@
 {% if persona and persona.revisions %}
 <section class="card">
   <h2 class="card__title">
-    Earlier personalities <span class="badge">{{ persona.revisions|length }}</span>
+    Earlier defaults <span class="badge">{{ persona.revisions|length }}</span>
   </h2>
   <p class="card__lede">
-    What it said before each change. This is the whole safety story for a model
-    that may rewrite itself: not a gate, but a record and a way back.
+    What this default said before each change. Each person's own personality keeps
+    its own history, which they can see and restore in their own settings — this is
+    the starting point's history, not theirs.
   </p>
   <ul class="model-list">
     {% for revision in persona.revisions %}