feat(event-subscriber): accept partial_update as a register write (refs #153)

The ACL upserts with PATCH, so every approval notification carries actie `partial_update`.
Accepting it makes the INGEDIEND → INGESCHREVEN transition project. `update` stays accepted
so a PUT-shaped write behaves the same; `destroy` deliberately does not — removing a
registration from the public register is its own decision, not a side effect of this one.

ADR-0030 records why the actie list is what it is.

services/event-subscriber/EventSubscriber.Application/Notification.cs

@@ -18,10 +18,20 @@ public sealed record Notification(
     string Actie,
     Uri ResourceUrl)
 {
-    /// <summary>A register record written to Objecten — <c>create</c> on submit, <c>update</c> on
-    /// approval, since the ACL upserts the same object for a registration (§8.6).</summary>
+    /// <summary>
+    /// A register record written to Objecten — <c>create</c> on submit and <c>partial_update</c> on
+    /// approval, since the ACL upserts the same object for a registration (§8.6).
+    /// </summary>
+    /// <remarks>
+    /// <c>partial_update</c> is what a PATCH actually reports: DRF routes it through the notifying
+    /// <c>update()</c> but names the action <c>partial_update</c>, and that is what Objecten puts in
+    /// the notification. <c>update</c> is accepted too, so a PUT-shaped write would project the same
+    /// way. <c>destroy</c> is deliberately not: removing a registration from the public register is
+    /// its own decision, not a side effect of this one.
+    /// </remarks>
     public bool IsRegisterRecordWritten =>
-        Kanaal == "objecten" && Resource == "object" && Actie is "create" or "update";
+        Kanaal == "objecten" && Resource == "object"
+        && Actie is "create" or "update" or "partial_update";
 
     /// <summary>The object holding the register record. For a <c>resource: object</c> notification
     /// Objecten sends the object as both <c>hoofdObject</c> and <c>resourceUrl</c> — the object is