Budgets can't be set on any of the built-in global categories

The seven built-in default categories (Food, Transport, Housing, Utilities, Entertainment, Health, Other) are what every new user starts with -- nobody has to create a category before they can log an expense. But now nobody can set a budget limit on any of them either: POST /budgets rejects every attempt to set a limit on a global category with "category does not exist or is not accessible," even though that same category works perfectly fine for logging expenses against. This defeats the budget feature for the overwhelming majority of users, who never get around to creating a custom category.

The visibility check in Handler.Upsert -- which is supposed to allow a budget on any category "global OR owned by the caller," exactly like every other category-visible check in this codebase -- now only accepts categories the caller privately owns. It dropped the "or it's a global category" branch, so user_id IS NULL (a global category) never satisfies it.

As any authenticated user, POST /budgets with category_id: 1 (the seeded "Food" global category) and a valid monthly_limit.

Expected: 200 with the created budget.

Actual: 400 "category does not exist or is not accessible".

This is the same "global-or-owned" visibility rule implemented correctly in at least two other places in this codebase (expenses.Repo.CategoryVisible, categories.Repo.IsVisible) -- the copy of this check inline in budgets.Handler.Upsert lost the OR user_id IS NULL clause, so it silently narrowed from "visible to you" to "privately owned by you," a real, easy-to-make inconsistency between several near-duplicate authorization checks scattered across a codebase.

Compare the inline visibility query in Handler.Upsert against expenses.Repo.CategoryVisible's query (same shape, same intent) a few files over -- they should be checking the exact same condition.