Use backend-only category data for resource filters

[thughari]

Motivation

• Ensure the category filter is authoritative and consistent by deriving options from persisted backend data instead of frontend defaults or currently-loaded pages.
• Prevent categories from being hidden or out-of-sync when users add/edit/delete resources by refreshing options from the server after mutations.
• Improve resource filtering UX by centralizing category logic on the API so all clients share the same category set.

Description

• Added a new backend endpoint GET /api/resources/categories implemented in CareerResourceController and backed by CareerResourceService#getAllCategories() to return distinct, sorted persisted categories.
• Implemented findDistinctCategories() JPQL query in CareerResourceRepository and exposed a service method to fetch categories from the database.
• Extended frontend ResourceService with getResourceCategories() and a small client-side cache that is cleared by invalidateCache(); also kept the paged getResources() shape and added create/upload/update/delete flows to invalidate caches.
• Updated ResourcesComponent to remove hardcoded category defaults, load backend category options via loadCategoryOptions() on init and after add/edit/delete, and bind the UI filter to backend-provided categories; updated resources.component.spec.ts mocks accordingly.

Testing

• Ran frontend unit test command npm --prefix frontend run test -- --watch=false --browsers=ChromeHeadless, which reached Karma but failed to launch ChromeHeadless because the binary is not available in this environment (test could not complete).
• Attempted frontend production build with npm --prefix frontend run build, which failed in this environment due to Google Fonts inlining returning HTTP 403 (external network/font limitation).
• Attempted backend tests with mvn -q test, which failed here because Maven could not resolve the Spring Boot parent POM from Maven Central (HTTP 403 in this environment).

---

Codex Task