Incorrect logic for 'edit-own' and 'delete-own' permissions

Problem/Motivation

In MicroContentAccessHandler.php, ‘own’ content is determined by $microcontent->getRevisionUserId()

case 'update':
        return AccessResult::allowedIfHasPermission($account, sprintf('update any %s microcontent', $microcontent->bundle()))
          ->orIf(AccessResult::allowedIf($account->hasPermission(sprintf('update own %s microcontent', $microcontent->bundle())) && $microcontent->getRevisionUserId() === $account->id())
            ->cachePerPermissions()
            ->cachePerUser());

Use of the revision owner user id here is wrong. Or, if intentional, it’s not how Drupal core and contrib modules generally work - they determine “own” content based on the author/owner value of the entity. Example for core media module in MediaAccessControlHandler.php

$is_owner = ($account->id() && $account->id() === $entity->getOwnerId());

// ... later ...

  case 'update':
    if ($account->hasPermission('edit any ' . $type . ' media')) {
      return AccessResult::allowed()->cachePerPermissions();
    }
    if ($account->hasPermission('edit own ' . $type . ' media') && $is_owner) {
      return AccessResult::allowed()->cachePerPermissions()->cachePerUser()->addCacheableDependency($entity);

Impact:

If a user’s edit and delete permissions are limited to edit-own and delete-own, they lose that access if an admin (etc) edits the item, because then the revision author would become that person.

Proposed resolution

Use $microcontent->getOwnerId() instead of $microcontent->getRevisionUserId()

Remaining tasks

I've built a patch, to be submitted shortly.