add new schema key for Category, and only create menu folders if menu_items > platforms > linux > Categories require them

### Checklist

- [x] I added a descriptive title
- [x] I searched open requests and couldn't find a duplicate

### What is the idea?

The `menu.json` schema should include a top-level key for `Category`, and the builder should look at the categories specified by the individual menu items when determining whether to create files associated with the new menu folder.

Currently the schema only specifies a `Categories` key under each entry in `menu_items > platforms > linux`. There is no way to control the new menu *folder's* category independently from its name. In other words, currently the builder creates `~/.config/menus/applications.menu` with the following (partial) content:

```xml

MENUNAME
SANITIZEDMENUNAME.directory

MENUNAME

```

Notice how MENUNAME gets used both as the name *and the include category*. This means if you want your new menu item(s) to appear in your new menu, you *MUST* specify in `menu.json` something like:

```json
{
"$schema": "...",
"$id": "...",
"menu_name": "MY MENU NAME",
"menu_items": [{
"name": "Specific shortcut name",
"description": "...",
"command": ["..."],
"platforms": {
"linux": {
"Categories": "MY MENU NAME" <----- CURRENTLY NECESSARY, BUT UNEXPECTED/CONFUSING
}
}
}]
}
```

### Why is this needed?

Because the user needs to enter "Categories" manually, they'll probably look at the XDG spec, see that it's possible to use builtin categories or make custom categories, and follow the advice to call theirs `X-My-Custom-Category`, e.g. https://wiki.xfce.org/howto/customize-menu which says:

> It is recommended to make up a custom category starting with “X-”, which is the prefix of non-standard categories by convention.

But this won't work (unless they name their menu folder "X-My-Custom-Category", which nobody would think to do).

### What should happen?

1. a new optional top-level "Category" key (ignored on Win/macOS I guess?) to define the Include Category of the new menu folder. If `null`, fall back to `menu_name`.
2. internal logic to examine the values in each `menu_items > platforms > linux > Categories` entry to see if the menu folder's category is even being used by any of the menu items. If not, don't bother creating the associated `.directory` file, and don't create/modify `applications.menu` either.

### Additional Context

Consider also a converse case, where one wants the menu items to go into one or more of Linux's default categories (Science, Development, Internet, Office, whatever) and doesn't want to create a new menu folder at all. In that case, each menu item can independently define which category or categories it should appear under, but *a new menu folder will still get created even if none of the menu items will show up inside it.* Luckily it's not as bad as it might be, because menu folders with zero included items are automatically suppressed by the desktop environment... but it still feels a bit "crufty" to be generating a `~/.local/share/desktop-directories/SANITIZEDMENUNAME.directory` that is not needed/used, and modifying `~/.config/menus/applications.menu` in ways that have no affect on the user. This case is what motivates point (2) in the "what should happen" section, above.

Start by locating the menu.json schema and the builder logic that generates applications.menu and .directory files for Linux. Verify how menu_name, Categories, and the proposed top-level Category are handled, then confirm the finished behavior: Category falls back to menu_name when null, and unused categories do not create or modify the associated menu files.

Written by the indexing model from the issue text.