fix(computing-unit): repair the owner-avatar accessor in the spec (#7633)

### What changes were proposed in this PR?

**`main` does not compile.** Any PR whose `build / amber` or `build /
amber-integration` jobs run after this landed fails on it regardless of
what the PR itself touches — #7631 is an example, where the only change
is four tests in an unrelated module's spec.

Scoping that honestly: PRs whose amber jobs ran *before* the breakage
still show green and would fail on re-run, and frontend-labelled PRs
skip the amber stack, so this is "every amber run from now until it is
fixed" rather than "every open PR is red today".

`ComputingUnitManagingResourceSpec` asserts on
`DashboardWorkflowComputingUnit.ownerGoogleAvatar`, but the field is
named `ownerAvatar`, so `ComputingUnitManagingService / Test` fails with
two "value ownerGoogleAvatar is not a member" errors.

Two PRs raced to produce it: #7563 renamed the field to `ownerAvatar`,
while #7580 added assertions written against the old name. Each was
green against its own base, and the combination is what breaks — the
kind of thing per-PR CI cannot see when two PRs touch different files.

This renames the two accessor calls. Nothing else changes.

### How was this PR tested?

Confirmed the breakage is real and that this is the whole of it, by
stashing the change and re-running on otherwise-clean `main`:

```
sbt "ComputingUnitManagingService/Test/compile"
```

| | Result |
|---|---|
| unpatched `main` | exit 1, exactly 2 × `value ownerGoogleAvatar is not
a member` |
| with this change | exit 0, compiles clean |

Then the spec itself:

```
sbt "ComputingUnitManagingService/testOnly org.apache.texera.service.resource.ComputingUnitManagingResourceSpec"
```

```
[info] Total number of tests run: 31
[info] Tests: succeeded 31, failed 0, canceled 0, ignored 0, pending 0
```

All 31 pass, so the assertions were correct about the value and only the
accessor name was stale. `Test/scalafmtCheck` and `Test/scalafix
--check` both pass.

### Any related issues, documentation, discussions?

Closes #7632

### Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 5)