Domain admin cannot write an app config fragment at their own domain scope

## Objective

A domain admin holds APP_CONFIG_FRAGMENT owner operations at their own domain scope but is refused when writing a fragment there. Let the write through, without widening it to any other domain.

## Background

A fragment scope is addressed by the domain's UUID (AppConfigScopeID), while a validation step on the write path keys on the domain name instead. The acting user's context carries both spellings - UserData.domain_name and UserData.domain_id - so the two can be compared against each other and never match, denying the domain admin their own scope.

Known issue: excluded from the current behaviour test run rather than treated as a test failure.

## Acceptance Criteria

- A domain admin upserts a fragment at scope_type=domain with their own domain id and it succeeds.
- A domain admin is still refused at another domain's scope.
- The superadmin path and a regular user's own user scope are unaffected.
- A regression test covers the domain admin writing at their own domain scope.

## Related

- BA-5781 - App Config API (global / domain / user scopes).
- src/ai/backend/common/data/user/types.py - UserData carries domain_name and domain_id side by side.

## Story Points

1

JIRA Issue: BA-7231

Trace the app-config fragment write validation and inspect src/ai/backend/common/data/user/types.py, where UserData exposes domain_name and domain_id. Start with the existing behavior-test coverage, including the currently excluded path, and add a regression case for a domain admin writing at their own domain scope. Done means that case succeeds while another domain remains denied and the unaffected paths still pass.

Written by the indexing model from the issue text.