Add multi-user auth, settings area, and unified label feed

Turns Daybook into a multi-user tool and reworks the feed UI:

- Multi-user: Django session login (username/password + remember-me),
  per-user personal API tokens (DRF authtoken), whole app gated behind
  login. Each artifact has an owner; feeds are private per user.
- Rename persona -> source (free-text label for whatever posted an
  artifact: agent-profile, script, or person). source + tags form one
  unified label system; single label filter matches tags, source has
  its own filter/column/sidebar.
- Settings area (gear/user menu, top-right): Account (view/regenerate
  token) and Demo Data (in-app button seeding one artifact per kind).
  User account management via Django admin (superusers only).
- Feed rework: rolling 7-day window with sticky inline date separators
  and infinite scroll; left sidebar is now a Sources list with per-source
  unread counts; artifact type shown as text after title; source in its
  own column.
- Unread tracking: read_at on Artifact, marked read when previewed,
  bold titles for unread, sidebar unread badges, old banner removed.
- Tag colours: global shared registry, hash-based default with optional
  per-tag override via tag_colors on POST/PATCH.
- Ingest: token resolves owner; same source name under two users' tokens
  stays isolated. daybook_post.py renamed persona->source, requires a
  real token, --check accepts a bearer token. Docs updated to match.

Migrations 0004-0008 rename persona, add owner (nullable -> backfill to
first superuser -> required), and add read_at. Fresh installs no-op the
backfill.

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

CLAUDE.md

@@ -2,15 +2,18 @@
 
 ## Project
 
-Daybook is a self-hosted Django + Django REST Framework web app where AI agents publish artifacts and a human browses them in a time-ordered, persona-filterable feed.
+Daybook is a self-hosted, multi-user Django + Django REST Framework web app where AI agents, scripts, or people publish artifacts and each logged-in user browses their own time-ordered, label-filterable feed.
 
 The core product principle is: agents publish content, not files. The server owns IDs, styling, storage layout, dates, and normalization into browser-native HTML, image, or PDF outputs.
 
 ## Current MVP Decisions
 
-- Use a single shared ingest API token for now.
-- Require `persona` in every artifact payload.
-- Do not add reader authentication in the local/self-hosted MVP.
+- Each user has a personal ingest API token (DRF `Token` model), viewable/regenerable from Settings → Account.
+- Require `source` in every artifact payload — a free-text label identifying what posted it (agent-profile, script, or person name). Ownership of the resulting artifact comes from whichever user's token authenticated the POST, not from the `source` value itself.
+- `source` and `tags` together form one unified **label** system: every artifact shows all its labels next to the title, and a single `label` filter/query param matches against either.
+- Require login (Django session auth) for the whole app, including the feed and API reads. Ingest (POST/PATCH) stays per-user bearer-token authenticated, since agents don't have browser sessions.
+- User accounts are created/managed via Django admin (superusers only — regular users are not staff and cannot access `/admin/`).
+- `TagColor` (label color overrides) stays global/shared across all users.
 - Use random 8-character artifact IDs.
 - Start as a plain Django project; add Docker after core ingest and viewer work.
 - Preserve original markdown as `.md` alongside rendered `.html`.
@@ -22,7 +25,8 @@ The core product principle is: agents publish content, not files. The server own
 - Main app: `artifacts/`.
 - Theme CSS: `static/themes/`.
 - Feed template: `templates/artifacts/feed.html`.
-- Stored artifact files live under `artifacts_store/{persona}/{YYYY-MM-DD}/`.
+- Settings templates: `templates/artifacts/settings_*.html`.
+- Stored artifact files live under `artifacts_store/{source}/{YYYY-MM-DD}/`.
 
 ## Implementation Guidelines
 
@@ -38,6 +42,8 @@ The core product principle is: agents publish content, not files. The server own
 - Develop and test locally in this workspace by default.
 - Use the local Django commands for normal iteration: `python manage.py check`, `python manage.py migrate`, and `python manage.py runserver`.
 - Run the local development server on `127.0.0.1:8001`. Port `8000` may be reserved or blocked on this workstation.
+- Always use this same fixed port for the dev server. Never start a second instance on a different port; if `8001` is already serving, reuse it rather than starting another.
+- All artifact-posting tools (`skills/daybook-posting/scripts/daybook_post.py`, `scripts/seed_demo_artifacts.py`, and any future posting skill) must default `DAYBOOK_URL` to `http://127.0.0.1:8001` to match.
 - Do not deploy to the Proxmox NUC during routine code iteration.
 - Treat the NUC container as the local live/staging target. Deploy there only at explicit stable checkpoints, such as an end-of-day build.
 - Before any NUC deployment, preserve `/opt/daybook/deploy/.env` and `/opt/daybook/deploy/data`.
@@ -60,9 +66,9 @@ The core product principle is: agents publish content, not files. The server own
 ## API Defaults
 
 - MVP ingest endpoint: `POST /api/artifacts`
-- MVP list endpoint: `GET /api/artifacts?persona=&day=&tag=`
+- MVP list endpoint: `GET /api/artifacts?label=&day=&kind=&q=`
 - Artifact view: `GET /a/{id}`
-- Development token: `Authorization: Bearer dev-token`
+- Auth: personal per-user token from Settings → Account, `Authorization: Bearer <token>`. Get one by creating a superuser (`python manage.py createsuperuser`), logging in, and visiting Settings → Account.
 
 ## Claude Code / OpenCode