Label-set creation and corpus selection provide incorrect frontend state

[angelo-lacson]

Summary

Several label-set workflows provide misleading or stale frontend state:

1. Creating a label can fail backend color validation because the frontend sends a bare hex value such as 0F766E, while the GraphQL validator requires a leading #.
2. The create flow currently treats any resolved mutation as success, even when createAnnotationLabelForLabelset.ok is false, and closes the form before confirming refreshed data.
3. Selecting a non-default label set in the create-corpus modal updates only the ID; the controlled selector continues to display the previous label set because the selected object is not propagated.
4. On populated label sets, the Add Label action is rendered after the full list, making it difficult to reach when many labels exist.

Reproduction

Label creation

1. Open an editable label set.
2. Add a text or span label using the color picker.
3. Submit the form.

Depending on the selected value, the backend rejects the bare hex payload with an Invalid color format message. The UI may nevertheless show a success notification or retain stale counts/list content.

Corpus label-set selection

1. Open Create New Corpus.
2. Open the Label Set selector.
3. Choose a label set other than Default Labels.

The dropdown continues to render Default Labels, so the user cannot verify that the new selection was applied.

Expected behavior

• Label colors are normalized to the backend-supported #RGB/#RRGGBB shape.
• Success feedback is shown only when the mutation payload reports ok: true, and refreshed label data is available before the form closes.
• The corpus modal immediately displays the selected label set.
• For a populated label type, Add Label remains beside the search field rather than below the entire list.

Scope

This is a frontend state, validation, and usability fix. It does not require a GraphQL schema or database change.