fix(service): correct notification throttle logic in ServiceManager.setMeta

[alirafiqmalik]

What does this PR do?

Fixes the notification throttle in ServiceManager.setMeta (if condition branch). Two bugs turned it into a no-op:

Root Cause

• Inverted condition. The ">=1s since last update" path scheduled a setTimeout instead of firing right away; the "<1s" path fired right away instead of deferring. The leading and trailing edge logic ran backwards.
• Broken delay. 1000 - now - this.lastNotifUpdate subtracts two epoch timestamps (results in negative values) instead of 1000 - (now - this lastNotifUpdate), so setTimeout fired on the next tick every time.

Net effect: BackgroundService.updateNotification ran on every setMeta call, once per novel during a library update, so 30-100 notification updates per sweep.

   ## Example illustrating the root cause

   Suppose:
   now = Date.now()           // e.g. 1,700,000,005,000 (current milliseconds)
   lastNotifUpdate            // e.g. 1,700,000,004,001 (last notification update time)
   
   if (now - lastNotifUpdate > 1000) { // ">1s since last update?"
     // INTENT: Enough time passed, fire updateNotification now
     // But calculates delay like this:
     delay = 1000 - now - lastNotifUpdate
     //       = 1000 - 1,700,000,005,000 - 1,700,000,004,001
     //       = 1000 - 3,400,000,009,001
     //       = -3,400,000,008,001
     setTimeout(fire, -3.4e12) //  ---> negative value, so fires IMMEDIATELY
   } else { // "<1s, should wait"
     // Due to broken logic, this branch also calls updateNotification() immediately
   }

Change Made

At src/services/ServiceManager.ts [lines 152-153], flipped the throttle condition and fixed the delay arithmetic.