`@JsonDeserialize` on a super class pointing to a sibling class makes Jackson deserialize using that sibling class

This at first sounds like a configuration issue on my end. But then I think Jackson could be a bit more clever here, or in fact in this case maybe it'd be less clever.

Suppose we have an interface with `@JsonDeserialize`:
```java
@JsonDeserialize(as = DataShapeImpl.class)
interface DataShape {
String getSomething();
}
```
and its implementation
```java
class DataShapeImpl implements DataShape { ... }
```

And now if we happen to have another implementation of the same interface:
```java
class ApiDataShape implements DataShape { ... }
```

then when I invoke deserialization pointing Jackson to the second implementation:
```java
ApiDataShape shape = objectMapper
.readerFor(ApiDataShape.class)
.readValue("{\"something\": \"foo\"}");
```

I'll get an exception saying `Failed to narrow type ApiDataShape with annotation (value DataShapeImpl)`. Meaning that Jackson decides to deserialize the given JSON to `DataShapeImpl` because it follows the `JsonDeserialize` annotation on the super-type, even though I asked it for `ApiDataShape` instance and those classes are not compatible with each other.

**Version information**
2.13 / master

**Expected behavior**
What I'd propose is that when Jackson reads the `JsonDeserialize(as = ...)` annotation on a super-type, that it tries to be more lenient with regards to the `JsonDeserialize` annotation on a super-type. There's actually a [comment in the code](https://github.com/FasterXML/jackson-databind/blob/2.13/src/main/java/com/fasterxml/jackson/databind/deser/DeserializerCache.java#L531) that leads to that exception, about whether Jackson should handle this a bit differently.
I think if `refineDeserializationType()` behaved differently when called from `modifyTypeByAnnotation()`, as the comment suggests, maybe that would work more in line with what is expected. Specifically, if `modifyTypeByAnnotation()` wouldn't fail like that and ignored the `JsonDeserialize(as = ...)` if types are not compatible.