How the handle an override of the schema of a field type
You have to write an update function that changes those fields live in your database so they match the new definition.
Time ago, this was done using the drush entity-updates command. However, this was dangerous in some circumstances. You can check the Support for automatic entity updates has been removed change record to get more information on this.
In this change record you can see:

Starting with 8.7.0, Drupal core no longer provides support for
automatic entity updates. Whenever an entity type or field storage
definition needs to be created, changed or deleted, it has to be done
with an explicit update function as provided by the Update API, and
using the API provided by the entity definition update manager.

Therefore, you need an update function. Probably, you should read the &quot;Updating Database Schema and/or Data in Drupal 8&quot; page, specially the &quot;Adding a new column&quot; section:

Here's an example of what to put into your hook_update_N() function to
add a new column to an existing database table:
  $spec = [
    'type' =&gt; 'varchar',
    'description' =&gt; &quot;New Col&quot;,
    'length' =&gt; 20,
    'not null' =&gt; FALSE,
  ]; 
 $schema = Database::getConnection()-&gt;schema();
 $schema-&gt;addField('mytable1', 'newcol', $spec);


Devel Entity Updates module
As pointed out by @Ales, you may try the Devel Entity Updates module:

This command should be able to fully replace the legacy drush entup or
drush entity-updates commands.

However, this module is not meant to be used in production environments, see the following disclaimer from the module:

The goal of this module is to have a quick way to apply schema updates
while developing new entity types and ending up incrementally
adding/removing/changing entity type/field definitions.
When these changes are part of an official release (and not in the
scope of a code development session), they should absolutely rely on
DB update functions, as explained in the CR above, because that's the
only way the entity schema update process can be predictable and
reliable.

So, this approach is ok for you if don't have a production environment yet. Of course, you can ignore the warning and install the module on prod, but keep in mind that you may lose data because the operation is not safe.
You can try it on a test environment, and if you finally take the risk and use in prod make sure you have a recent backup at hand.
Why you need this
The problem you have a difference between the table data definition in code and the actual data tables in your database. Why does this happen? There are different circumstances that can lead to this. In your case, the State module has some data definitions that are applied when the module is installed. At this point, code data definition and actual data tables are matching. However, if you make any changes on the code that defines the data tables the problem arises: you have one definition on code and different actual data tables in the database.
So what you need to do is modify the tables to match the data definition. That's what my answer tries to explain. The two methods are writing an update function (so you control with that function how to modify the actual tables) or trust an automatic method (the entity update command). The command is easy but it has no brain so it just modifies the tables without thinking on possible issues. That's why you may have problems (data loss, mainly) using that command.