Easy to forget to create custom attributes before storing the data

## Problem

In a recent project I'm in, some developers uses a new custom attribute without creating it in the portal first.
They didn't know the data were not stored and some production data were lost after deployment.

## Appetite

2 weeks

## Solution

few ideas for this problem:

### Warn developers when storing an inexistent attribute

- We still keep the requirement of first creating the attribute, but return a clear error message when the developer attempt to update an inexistent custom attribute

### Always accept user attributes

- When the user attribute key does not match any of the created, store it in the database but hidden from any view.
- When the developer creates the key later, the stored value is shown.

Cons: Hard to do validation and maybe a lot of hidden data stored.

### Allow a json object in the user attribute

- The user can store a JSON object freely to a user attribute with a size limit, so they can use different shape of data for different users.

Cons: These attributes are very difficult to be presented in the portal and `/settings` page as editable fields.

No files or tests are identified. Start by reviewing the existing custom-attribute update flow, the portal and database behavior, and the /settings page; compare the proposed warning, unrestricted storage, and JSON-object approaches. Done requires a decided behavior that prevents silent data loss and accounts for validation and presentation.

Written by the indexing model from the issue text.