Updated CHANGELOG

CHANGELOG.md

@@ -71,6 +71,7 @@ All notable changes to Bambuddy will be documented in this file.
 - **Two inventory notification toggles could never be turned on, so stock alerts have never been able to fire (#2945, reported by @ojimpo; regression tests contributed by @ojimpo in #2956)** — `on_stock_reorder_alert` and `on_stock_break_alert` exist as columns on a notification provider, have their own templates, and `notification_service` looks providers up under exactly those names before sending. The whole UI is there too: a toggle in Add/Edit Notification, a badge on the provider card, the field in the API client's types, and tests for all of it. The one thing missing was the schema. `NotificationProviderCreate`/`Update` never declared either field, and Pydantic drops what it does not declare, so every request that carried them came back `200 OK` with the row unchanged — and `_provider_to_dict`, which is a hand-maintained field-by-field map, never returned them either, so the toggle read back off no matter what the database held. Nothing errored anywhere along that path. Both directions are wired now, and the round-trip tests that already covered the Home Assistant toggles cover these too, because the failure is structural rather than particular to one field: any column missing from those two maps is invisible to a test that builds providers through the ORM, and only a create-then-re-read through the route catches it. This makes the setting stick and report itself honestly; what actually sends the alerts is the #2955 entry above. The tests no longer depend on anyone remembering the next field, either. They now read the list of provider fields from the database model itself, so a toggle or setting added later is checked from the day its column exists, with no new test to write. It must be accepted when a provider is created and when it is edited, and every toggle must survive a save and read back from both the single-provider and the list endpoint. Each toggle is set to the opposite of its default for that check, because nine of them default to on and a test that saves "on" and reads back "on" would pass even if the value were silently dropped.
 
 ### Security
+- **Bumped `PyJWT` to 2.15.1 and `urllib3` to 2.8.0** — PyJWT 2.14 and 2.15 fix thirteen advisories, most of them algorithm confusion when one `decode()` call accepts both an HMAC and an asymmetric algorithm, and JWKS fetching through `PyJWKClient`. Bambuddy's session tokens accept only HS256, and SSO fetches the identity provider's key set itself before handing it to PyJWT, so neither path was open to these. The fixes for deeply nested or malformed tokens, and for JWK Sets with one bad key (which now skip that key instead of failing the whole set), do reach the SSO sign-in. urllib3 2.8.0 fixes three advisories in response streaming and HTTPS-proxy TLS; Bambuddy doesn't use urllib3 itself, it arrives through other packages. `virtualenv`, which only the development tools pull in, is pinned to 21.7.13 or later so `pip-audit` stays clean.
 - **Bumped `dompurify` to 3.4.16 for a low-severity DOM XSS advisory** — In 3.4.13 to 3.4.15, sanitizing with `IN_PLACE` and an `afterSanitize` hook that removes nodes could leave event handlers armed on the detached subtree. Bambuddy uses DOMPurify for project notes, project pages and MakerWorld descriptions, always with a plain `sanitize()` call, no `IN_PLACE` and no hooks, so it was not exposed. The bump keeps the dependency clean.
 - **Bumped `js-yaml` to 5.4.2 for a merge-key denial-of-service advisory** — In versions up to 5.4.0, the `maxTotalMergeKeys` limit does not count empty mappings. A small YAML document that merges a long list of `{}` many times (`<<: *arr`) can keep the CPU busy for seconds per few hundred kilobytes without ever reaching the limit. It only applies when merge keys are enabled, which means the YAML 1.1 schema. The fix counts each merged mapping towards the budget. **No running Bambuddy install was exposed, and the issue was not reachable at build time either.** `js-yaml` is a development-only transitive dependency, pulled in by `eslint` through `@eslint/eslintrc`, and it is not in the shipped image. `@eslint/eslintrc` only parses legacy `.eslintrc.yaml`/`.eslintrc.yml` files, and this repository has none. Linting uses the flat `frontend/eslint.config.js`, so no YAML is loaded at all. The existing `overrides` pin in `frontend/package.json` moves from `^5.2.3` to `^5.4.1`, so a regenerated lockfile cannot resolve back below the fix. The lockfile changes in one entry only, with nothing added or removed, and the shipped bundle does not change. Verified with eslint, typecheck, the production build, and the full frontend suite (4022 tests across 297 files). `npm audit` reports no `js-yaml` findings.
 - **Bumped `brace-expansion` to 5.0.12 for three denial-of-service advisories** — Two high-severity issues, fixed in 5.0.10 and 5.0.11, let deeply nested brace groups exhaust the native stack. Roughly 3,100 levels of `{{{...a,b...}}}`, about 6 KB of input, crashed the process: once through the recursive comma splitter and once through the expander itself. The medium-severity third, fixed in 5.0.12, is the bash `{a},b}` quirk. The parser handles it by rewriting the string and rescanning once per trailing `}`, so the cost grows quadratically, and 128 KB of input blocked the event loop for 27 seconds. 5.0.12 makes the comma splitter iterative and caps nesting depth and rewrite passes at 1,000 each. Input past either cap is kept as plain text rather than throwing, the same way the existing `max` and `maxLength` limits work. **No running Bambuddy install was exposed, and none of the issues was reachable at build time either.** `brace-expansion` is a development-only transitive dependency, pulled in by `eslint` through `minimatch`, and it is not in the shipped image. The only patterns it ever expands are the fixed globs in `frontend/eslint.config.js`. Before the bump, the output of 5.0.9 and 5.0.12 was compared on every glob in that file plus ranges, nested sets, escaped braces and the `{a},b}` quirk, and it was identical. The same comparison confirmed the fixes: 5,000 levels of nesting overflow the stack on 5.0.9 and expand cleanly on 5.0.12, and a 20,000-brace rewrite input drops from 3 seconds to 13 ms. The existing `overrides` pin in `frontend/package.json` moves from `^5.0.9` to `^5.0.12`, because `minimatch` still asks for only `^5.0.2`. The lockfile changes in one entry only, `balanced-match` is untouched, nothing is added or removed, and the shipped bundle does not change. Verified with eslint, typecheck, the production build and the full frontend suite (4022 tests across 297 files). `npm audit` reports zero vulnerabilities with and without dev dependencies.