[Bug]: Quirks while deriving models

### Describe the bug

I can not find the right strategy to work with visibility filters.
Below are some examples.

Please explain how to cope with.

TIA

### Reproduction

Example 1:
```tsp
using Reflection;

model Foo {
id: string,
parent_id: Foo.id,
parent: Foo,
}

// NB: FilterVisibility _does require_ the name argument
alias GuessReadType = FilterVisibility;

// Duplicate type name: 'FooRead'
model FooRead is GuessReadType {}
```

Example 2:
```tsp
using Reflection;

// Duplicate type name: 'Foo'
model Foo {
id: string,
parent_id: Foo.id,
parent: Foo,
}

// NB: FilterVisibility _does require_ the name argument
alias GuessReadType = FilterVisibility;

model FooRead is GuessReadType {}
```

### Checklist

- [x] Follow our [Code of Conduct](https://github.com/microsoft/typespec/blob/main/CODE_OF_CONDUCT.md)
- [x] Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
- [x] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/Microsoft/typespec/discussions).
- [x] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

Start with the two minimal reproductions in issue #11720 and inspect how Reflection's FilterVisibility derives model names. Compare the behavior when the name argument is "{name}" versus an empty string, then determine the expected handling of duplicate names. Done means the reported quirks have a documented or verified resolution without duplicate type-name diagnostics.

Written by the indexing model from the issue text.