Prevent migration notifier from rate-limiting itself off (#6174)

omarchy-update-user-notify.path watches /usr/share/omarchy/migrations
with PathModified. A single update commonly drops several migration
files at once, so the oneshot service is re-triggered in a burst and
exceeds the default start-rate limit (StartLimitBurst=5 / 10s):

  omarchy-update-user-notify.service: Start request repeated too quickly.
  omarchy-update-user-notify.path: Failed with result 'unit-start-limit-hit'.

When the limit trips, the watching .path unit itself fails and stops
watching, so migrations that land later in the session are never
surfaced until the next login.

Set StartLimitIntervalSec=0 on the service. omarchy-migrate-notify is
idempotent, so there is no downside to letting it run on every trigger.

Co-authored-by: Claude <noreply@anthropic.com>

default/systemd/user/omarchy-update-user-notify.service

@@ -1,6 +1,13 @@
 [Unit]
 Description=Notify about pending Omarchy migrations
 ConditionPathIsDirectory=/usr/share/omarchy/migrations
+# A single update can drop several migration files at once, so the .path
+# unit re-triggers this oneshot in a burst. Without this, the default
+# start-rate limit (5 starts / 10s) trips and the watching .path unit
+# itself dies with 'unit-start-limit-hit', silently stopping migration
+# notifications for the rest of the session. The notifier is idempotent,
+# so disable the start-rate limit.
+StartLimitIntervalSec=0
 
 [Service]
 Type=oneshot