rename the TIC system agent to event triage

TIC said nothing about what the agent does, and named the wrong thing: the
tick belongs to the scheduler, which is generic and lives outside it. The
agent's only decision is whether an incoming event deserves an interruption
— it sorts, it never acts — so it is now event-triage, matching the
functional naming of the two memory lints.

- agents/tic/ -> agents/event-triage/, module tic/ -> event_triage/,
  TicManager -> EventTriageManager, TicConfig -> EventTriageConfig
- agent id and chat source: "tic" -> "event-triage"
- config keys: tic.* -> event_triage.*, and the config.yml section tic: ->
  event_triage: (greenfield: previously set values fall back to defaults)
- i18n en/it/fr: Event triage / Triage eventi / Tri des evenements; dropped
  the stale "TIC sessions" mention from the debug-pages description
- docs/system-agents.md, docs/index.md, docs/settings.md, CLAUDE.md, SKALD.md

docs/index.md

@@ -12,7 +12,7 @@ This index will grow over time. Right now it covers memory, projects, system age
 | --- | --- |
 | [memory.md](memory.md) | Private and shared memory: what goes where, the indexes and history log, why some shared facts can't be changed on request |
 | [projects.md](projects.md) | Projects: shared folders with their own assistant chat, a live file explorer, and member sharing |
-| [system-agents.md](system-agents.md) | Background agents that run on a schedule (TIC, the two memory lints): what they watch, why they only ever report, why a run can be skipped, and their settings |
+| [system-agents.md](system-agents.md) | Background agents that run on a schedule (event triage, the two memory lints): what they watch, why they only ever report, why a run can be skipped, and their settings |
 | [settings.md](settings.md) | The admin's Config page: interface language, the compaction model picker, debug mode |
 
 ## Plugins

docs/settings.md

@@ -10,7 +10,7 @@ Each setting is saved individually with its own **Save** button (a few, like the
 
 ## Background agents — not here
 
-The settings for the background agents (TIC, the two memory lints) are **not** on this page. Each one is configured on its own tab of the **System agents** page, next to that agent's run history — see [system-agents.md](system-agents.md).
+The settings for the background agents (event triage, the two memory lints) are **not** on this page. Each one is configured on its own tab of the **System agents** page, next to that agent's run history — see [system-agents.md](system-agents.md).
 
 They are still admin-only, and still instance-wide. They simply live where their run log is, because "why did this agent do nothing last night?" is usually answered half by the schedule and half by the log.
 

docs/system-agents.md

@@ -6,7 +6,7 @@ There are three:
 
 | Agent | What it watches | How often |
 | --- | --- | --- |
-| **TIC** | events arriving from that person's connectors | every few minutes |
+| **Event triage** | events arriving from that person's connectors | every few minutes |
 | **Private memory lint** | that person's own memory notes | weekly |
 | **Shared memory lint** | the group's shared memory | weekly |
 
@@ -16,13 +16,13 @@ They share three habits worth stating once, because they explain most of what pe
 - **An empty run is a correct run.** They are not supposed to find something every time, and they stay quiet when they don't.
 - **They run per person, on that person's own things**, with one exception noted below.
 
-## TIC
+## Event triage
 
 Connectors (Gmail, a calendar, WhatsApp…) push events into the system as they happen — a new message arrives, a meeting is moved. Those events pile up quietly; nothing interrupts anyone.
 
-Every so often TIC wakes up and reads the batch that accumulated since last time. For each event it decides whether it is worth the interruption, using what it knows about that person from their private memory: who matters to them, what they are working on, what they have said they want to be told about. Events that pass become notifications in their Inbox. Events that don't are simply marked as seen — a newsletter or a group chat with nothing relevant in it produces nothing.
+Every so often event triage wakes up and reads the batch that accumulated since last time. For each event it decides whether it is worth the interruption, using what it knows about that person from their private memory: who matters to them, what they are working on, what they have said they want to be told about. Events that pass become notifications in their Inbox. Events that don't are simply marked as seen — a newsletter or a group chat with nothing relevant in it produces nothing.
 
-TIC never replies to a message or moves a calendar event. If an event needs an action, it says so in the notification.
+The name is the limit of the job: it **sorts**, it never acts. It will not reply to a message or move a calendar event. If an event needs an action, it says so in the notification and the person decides.
 
 ## The two memory lints
 
@@ -76,7 +76,7 @@ A run appears **only when there was something to look at**. Long gaps mean quiet
 Each agent's tab carries the same three settings, visible only to an admin:
 
 - **Enabled** — turns that agent on or off for the whole instance, for everyone.
-- **Interval** — how long between passes for each person. TIC is in minutes, the lints in days.
+- **Interval** — how long between passes for each person. Event triage is in minutes, the lints in days.
 - **Security group** — which tools the agent may use during a run. It is re-checked against each user's own role: if their role does not allow that group, their run uses their role's default group instead. Nobody's background agent gets more access than their role would give them.
 
 There is no per-user on/off switch: if an agent is enabled, it runs for everyone who has logged in.