add categories for break ideas

[ptandler]

Issue: #1596

Requirements

• issue was opened to discuss proposed changes before starting implementation. It is important do discuss changes before implementing them (Why should we add it? How should it work? How should it look? Where will it be? ...).
• during development, node version specified in package.json was used (ie using nvm).
• package versions and package-lock.json were not changed (npm install --no-save).
• app version number was not changed.
• all new code has tests to ensure against regressions.
• npm run lint reports no offenses.
• npm run test is error-free.
• README and CHANGELOG were updated accordingly.
• after PR is approved, all commits in it are squashed

Description of the Change

As first step, I added 7 categories as proposed in #1596 (comment)

I'd suggest to use the idea ID's prefix to identify the category, as this makes handling the ideas easier and we don't need to maintain an additional prop for the category.

Next step would be to improve IdeasLoader & Shuffed

Verification Process

Other information

[steveszat]

I like the direction here — adding structure to break ideas makes a lot of sense.

Before getting into implementation details, I stepped back and thought about how I’d approach this if I were designing it from scratch.

To me, break ideas feel more like content than general application settings. So, I’d probably think in terms of:

• a message library (the ideas themselves)
• categories (eye relief, stretching, focus, etc.)
• user preferences (which categories are enabled)
• scheduling and presentation as separate concerns

In that model, messages would be structured objects with category metadata, and managed somewhat independently from the rest of the app configuration.

Given where things are today, it seems like we can still move toward something like this incrementally.

One idea would be to introduce a small abstraction for loading break ideas instead of reading them directly from settings. That would make it easier to:

• normalize message structure
• add categories cleanly
• evolve the storage later if needed

I’m fully on board with adding categories — this just seems like a way to make the change easier to extend and maintain over time.

Curious how you’re thinking about it, or if you have a different approach in mind.