Unexpected schema revision used when updating resources

_reported internally by @annakristinkaufmann_

**Describe the bug**
I was trying to update a resource which had been validated against a schema which itself has been updated in the meantime. The resource update includes changes which are incompatible with the previous revision of that schema, which is why I want to validate the resource against the latest revision of that given schema. When specifying the schema in the `url` for the `PUT` request, no schema revision needs to be specified. The resource seems to validate against the latest revision of the schema. I.e. in the below example, the resource validates against the latest revision of the `datashapes:cellrecordseries`:

```
PUT https://nexusdomain/nexus/v1/resources/{org}/{proj}/datashapes:cellrecordseries/{uuid}?rev=1
```

However, when not specifying the schema in the `url` for the `PUT` request, the resource is being validated against the **old version** of the schema (for which validation now fails):

```
PUT https://nexusdomain/nexus/v1/resources/{org}/{proj}/_/{uuid}?rev=1
```

The behaviour I consider as non-desired is that even after updating against the latest revision of the schema, if I want to perform yet another update, I again experience the same behaviour (i.e.validation happens against a prior revision of the schema), even if I have already performed an update against the latest schema revision prior to that update-attempt. I.e. the following fails again if not providing a schema id:

```
PUT https://nexusdomain/nexus/v1/resources/{org}/{proj}/_/{uuid}?rev=2
```

**What part of Nexus is affected**
- [ ] Fusion
- [x] Delta
- [ ] CLI
- [ ] Documentation

**Expected behaviour**
1. if a resource is created against the latest revision of a schema, when performing an update, the validation should use the new latest schema revision, without the need to specify the schema again
2. if a resource is created against a specific revision of a schema (via a tag or rev qualifier) the validation should always use that very specific schema revision... either the exact revision or the revision represented by the tag at the moment when the update is performed