[Bug] @dependentKeyCompat Doesn't Always Cause Computed Properties to Recompute

### 🐞 Describe the Bug

I have a computed property that is dependent on a native getter decorated with `@dependentKeyCompat`. Under normal circumstances when I modify a property, the change is detected and things re-render correctly. But I've noticed that when a modification is made, and the native getter is accessed (before things have a chance to re-validate), the change won't be detected and the computed property doesn't recompute.

### 🔬 Minimal Reproduction

I've created a [scenario](https://stackblitz.com/edit/ember-cli-editor-output-2gehf2?file=app%2Fcomponents%2Finterop-component%2Ftemplate.hbs) to reproduce this issue but I'll also explain the gist here.

Create a native class with `@tracked` properties and a native getter. Add an action to modify the property in addition to accessing it. You can simply `console.log` the value.

```ts
import { tracked } from '@glimmer/tracking'
import { action } from '@ember/object'
import { dependentKeyCompat } from '@ember/object/compat'

export default class Delegate {
@tracked
data = 0

@dependentKeyCompat
get computedData() {
return this.data
}

@action
update() {
++this.data
console.log(this.computedData)
}
}
```

Tie this together with a classic component.

```ts
import Component from '@ember/component'
import Delegate from './delegate'
import {computed} from '@ember/object'

export default class extends Component {
delegate = new Delegate()

@computed('delegate.computedData')
get computedData() {
return this.delegate.computedData
}
}
```

```hbs

Update
```

### 😕 Actual Behavior

When you click the button, the value of `this.computedData` is empty.

### 🤔 Expected Behavior

I would expect that regardless of `computedData` being accessed directly, the computed property would have recomputed, just like any computed property in classic components would if you called them directly in your code.

### 🌍 Environment

- Ember: - 5.2.0
- Node.js/npm: - 16.20/9.4.2
- OS: - Mac
- Browser: - Chrome

### ➕ Additional Context

I've attempted to troubleshoot this myself and as far as I can tell, it seems that calling the native getter directly, doesn't actually compute a new value for the property tag. It does seem to compute the `subtag` and the `subtagBufferCache` but not the property tag itself. I can only speculate but it appears that after `re-validation` occurs, it keeps the old revision number as seen [here](https://github.com/glimmerjs/glimmer-vm/blob/68d371bdccb41bc239b8f70d832e956ce6c349d8/packages/%40glimmer/validator/lib/validators.ts#L148).