Address review: dedicated DoesNotExist handler, stable error msgs, CHANGELOG split

- CreateLabelForLabelsetMutation now matches Remove's exception handling: explicit LabelSet.DoesNotExist branch logs at WARNING (no stack trace) and falls through to a clean 'matching query does not exist' message, while the catch-all uses logger.exception() for genuine errors.
- Both mutations now build the deny-path message from a stable string instead of instantiating a DoesNotExist purely to call its __str__ (Django version coupling).
- Split the long CHANGELOG entry into two focused bullets, one per mutation, matching the per-fix style of the surrounding entries.

Author: JSv4

CHANGELOG.md

@@ -19,7 +19,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Security
 
-- **Labelset-membership mutations now enforce the documented edit-rights model** (`config/graphql/label_mutations.py`, `CreateLabelForLabelsetMutation` and `RemoveLabelsFromLabelsetMutation`): Both resolvers previously made the wrong scope call. `Remove` used `Q(creator=user) | Q(is_public=True)` with no further check, so any logged-in user could strip labels from another user's *public* labelset. `Create` was creator-only, so a collaborator with explicit `update_labelset` guardian permission (or a group grant) could not add labels even though the consolidated permissioning guide says edit rights on a `LabelSet` should permit add/remove/edit of its labels. Both now fetch the labelset by pk and gate mutation on `user_has_permission_for_obj(user, labelset, PermissionTypes.UPDATE, include_group_permissions=True)`, raising `LabelSet.DoesNotExist` on denial so the response message and code path are identical to the not-found case (no IDOR information leak). Test coverage in `opencontractserver/tests/test_label_mutations.py`: `test_remove_labels_rejects_non_owner_even_when_labelset_is_public` (replaces the prior permissive test) confirms `is_public` alone does not grant write; `test_remove_labels_allows_non_owner_with_explicit_update_permission` pins the edit-rights model. The unused `Q` import was removed.
+- **`RemoveAnnotationLabelsFromLabelsetMutation` allowed any user to strip labels from public labelsets** (`config/graphql/label_mutations.py`): The resolver used `Q(creator=user) | Q(is_public=True)` with no further check, so `is_public` (a read flag) effectively granted write access to non-owners. Replaced with `user_has_permission_for_obj(user, labelset, PermissionTypes.UPDATE, include_group_permissions=True)`. Denial raises `LabelSet.DoesNotExist` so the response is byte-identical to the not-found case (no IDOR information leak). Coverage: `test_remove_labels_rejects_non_owner_even_when_labelset_is_public`.
+- **`CreateLabelForLabelsetMutation` ignored guardian UPDATE grants** (`config/graphql/label_mutations.py`): The resolver was creator-only, so collaborators with explicit `update_labelset` guardian permission (or a group grant) could not add labels even though the consolidated permissioning guide says edit rights on a `LabelSet` should permit add/remove/edit of its labels. Now uses the same `PermissionTypes.UPDATE` gate as `Remove`, with the matching IDOR-safe deny path. Coverage: `test_non_owner_with_explicit_update_permission_can_create`. Both mutations now have a dedicated `LabelSet.DoesNotExist` handler that logs at WARNING (not ERROR) so auth probes don't pollute logs with stack traces.
 - **Cross-corpus structural-annotation leak in `CoreAnnotationVectorStore`** (`opencontractserver/llms/vector_stores/core_vector_stores.py:296-326,371-413`): The corpus-wide retrieval path (`corpus_id` set, `document_id=None`) returned every structural annotation in the database regardless of corpus. Two collaborating defects caused the leak:
   1. `Q(structural=True)` in the corpus-only branch had **no corpus constraint** — parser-produced structural annotations have `Annotation.document_id = corpus_id = NULL`, so corpus membership is only knowable through `structural_set → Document.structural_annotation_set (reverse FK) → DocumentPath.corpus_id`, a join the previous code did not perform.
   2. The `check_corpus_deletion` block (default `True`) added `Q(document_id__in=active_doc_ids)`, and `__in` lookups never match `NULL`, so structural annotations were silently dropped on the production-default path. Bypassing this filter with `check_corpus_deletion=False` exposed defect #1 directly.

config/graphql/label_mutations.py

@@ -282,7 +282,20 @@ def mutate(
             message = "SUCCESS"
             logger.debug("Done")
 
+        except LabelSet.DoesNotExist:
+            # Legitimate auth rejection or genuine 404 — log without a stack
+            # trace to avoid polluting logs with what looks like real errors.
+            logger.warning(
+                "CreateLabelForLabelsetMutation: labelset not found or "
+                "permission denied (labelset_id=%s)",
+                labelset_id,
+            )
+            message = (
+                "Failed to create label for labelset due to error: "
+                "LabelSet matching query does not exist."
+            )
         except Exception as e:
+            logger.exception("CreateLabelForLabelsetMutation failed")
             message = f"Failed to create label for labelset due to error: {e}"
 
         return CreateLabelForLabelsetMutation(
@@ -336,7 +349,8 @@ def mutate(root, info, label_ids, labelset_id):
                 labelset_id,
             )
             message = (
-                f"Error removing label(s) from labelset: {LabelSet.DoesNotExist()}"
+                "Error removing label(s) from labelset: "
+                "LabelSet matching query does not exist."
             )
         except Exception as e:
             logger.exception("RemoveLabelsFromLabelsetMutation failed")