fix(templateengine): reject instance/script/alarm/slot names that are not valid actor names at save (review 2026-10-21 01/SR-C1)

docs/requirements/Component-TemplateEngine.md

@@ -93,6 +93,23 @@ When a template composes a feature module, members from that module are addresse
 - The composing template's own members (not from a module) have no prefix — they are top-level names.
 - Naming collision detection operates on canonical names, so two modules can define the same member name as long as their module instance names differ.
 
+### Runtime actor-name rules (review 2026-10-21 01/SR-C1)
+
+Some names become Akka actor names at the site: the instance **unique name** (the
+Instance Actor), and every **script**, **alarm** and **native alarm source**
+canonical name (`script-…`, `alarm-…`, `native-alarm-…` children of the Instance
+Actor) — which also embeds every **composition slot** name on its path. Akka accepts
+only ASCII letters, digits and `-_.*$+:@&=,!~';` (plus `%HH` escapes) and no leading
+`$`; anything else (a space, `#`, `/`, non-ASCII letters) makes `ActorOf` throw at
+deploy — for an instance name, inside the site's Deployment Manager singleton. The
+Template Engine therefore rejects such names **at save** with a readable error, using
+the shared `Commons.Validation.ActorNameRules`: `InstanceService.CreateInstanceAsync`
+(unique name), `TemplateService.AddScriptAsync` / `AddAlarmAsync` (member names are
+immutable after creation, so updates need no check) and `AddCompositionAsync` /
+`RenameCompositionAsync` (slot names). Attribute names and template names are not
+actor names and are unrestricted. Native alarm sources are created outside
+`TemplateService` (Management Service / Transport import); those paths must apply the same rule.
+
 ### Derived template naming
 
 A composition slot is materialized as its own *derived* template. A derived