[Logic Improvement] Enable notifications for the first iteration of the scanner when the state is empty

[ThomasDelsart]

In this first iteration of the scanner, the self.state variable is initialized as an empty dictionary and only populated after the first notification command is executed. This means that in the initial scan, notifications are not sent for magic bags already available in the TGTG application.

Since the second scan does not detect changes (if no new magic bags are added), no notifications are sent for the already available magic bags.

To address this, I propose a minor logic improvement by initializing the self.state variable before the first notification command is triggered.

Additionally, to pass the pre-commit checks, I ran poetry lock to update dependencies, as poetry lock --no-update was unsuccessful. The app continues to run smoothly with these changes.

[ihor-chaban]

I think the current behavior is intended.
The purpose of scanner is to notify you about the changes over time.
In order to see what bags are currently available you can simply open the app at any given moment.
So startup notifications for all currently available bags doesn't seem very useful and, in fact, may be redundant.
This is somewhat similar to the existing test notification but with real data instead.

If you like to merge this feature, I would suggest to add a configuration variable to enable/disable it and to sync it with the existing test notification, as both test notification and real notifications on startup are not needed.
Also it should be possible to not send any notifications on startup.