docs(KeyEquality): Re-Add KeyEquality Extension to the TOC and fix broken Link in ListStates Updating Operator docs

[DevTKSS]

GitHub Issue (If applicable): closes #2831

PR Type

What kind of change does this PR introduce?

• Documentation content changes

What is the current behavior?

1. Broken Link in ListState docs -> could only find this existing by using the searchbar
2. KeyEquality Docs are currently detached from the docs, which causes 1.
3. The KeyEquality Docs section for generation we are meaning to link are not telling about the limitation that this is not usable with simple types like e.g. string/uri ... which could eventually be readed from the beginning of the doc which we are not seeing if we are directly send to the generation chapter of it.

What is the new behavior?

• Re-added the KeyEquality Docs to the Extensions>Overview>... TOC branch where I would assume this does belong
• Checked the xref link if it still matches the uid in the doc and linked section in there
• Checked the KeyEquality Docs to clarify especially in this linked section that this Feature does NOT support simple types then only complex types (records/classes maybe too).

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs
• Docs have been added/updated which fit documentation template. (for bug fixes / features)
• Unit Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
• Wasm UI Tests are not showing unexpected any differences. Validate PR Screenshots Compare Test Run results.
• Contains NO breaking changes
• Updated the Release Notes
• Associated with an issue (GitHub or internal)

Other information

Maybe this Docs of KeyEquality should get split into two or more parts?

Part 1:
[

• Concept
• IKeyEquatable<T>
• Generation - are there other ways beside Attributes?
  ]
  Part 2:
  [
• KeyEqualityComparer
• (Here should get added some sample usage code, there is none for this!)
  ]

I am not sure if I did it right in my last application code and this docs page is a bit jumping in reading flow in my opinion. If I would have understand it better I would try to help but...

First you tell us about key equality generally, not using any of them both on the side below. You tell "Name" would be the Key, in the shown szenario, but you dont use any of the attributes and its not named "Key" or "Id" as you state there.
then you come up with the Interface we (assuming) would need to inherit from(?) and the KeyEqulityComparer<T>...
But beside the Attributes you then use the difference is not really getting clear from this. 🤔 If this KeyEqualityComparer<T> should be reffering to some Microsoft type, then we maybe "just" miss a link we could easily add for clarification, if those MS Docs would then give us the base idea of how you assume us to understand this extension Uno Provides to us 👍

Internal Issue (If applicable):

[Copilot]

Pull Request Overview

This PR adds documentation for the KeyEquality feature and updates cross-references to point to the new documentation structure. The documentation is reorganized to appear under its own section rather than being referenced by an older namespace reference.

• Adds KeyEquality section to the documentation table of contents
• Updates cross-reference links from the old Uno.Extensions.Equality namespace to Uno.Extensions.KeyEquality
• Reformats the concept.md file (adds line numbers without content changes)

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
doc/toc.yml	Adds KeyEquality section to the documentation navigation
doc/Learn/Mvux/ListStates.md	Updates cross-reference link and clarifies that generation applies specifically to records
doc/Learn/KeyEquality/concept.md	Reformats file with proper line numbering and minor documentation improvements

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[DevTKSS]

@kazo0 hey could you maybe check if we can re-attach this docs to our TOC? They are linked in the MVUX ListState.UpdateItemAsync but its kind of difficult to follow up the compiler warnings when I e.g. use not KeyEquality possible string types and be wondering why the heck this is not working as expected, not noticing that we are required to create even for create simple strings an additional Datatype 👀

yes, meanwhile I recognized that they are just not intended to be used in this, but as exactly this has caused one of the Root problems a User that was watching my videos was facing hand we tryed honestly about 4 hours until we did fall back to either had to use UpdateAllAsync(x => x == y) or using RemoveAsync(item) + then AddAsync(item) only to update those simple string Items:

• [Docs][Mvux][ListState] UpdateItemAsync is not possible like showed in the docs if the item is a simple string #2881

I think I also attached the video on the Bug report if you like to watch fail compilations of beginners 😬
Therefore I would at least like to re-attach those docs and added the note also above the ## Generation Heading which the MVUX Docs are linking to, but nobody of us did consider that if we are redirected to the middle of the file, we would have to read the whole file instead to maybe understand, that its just not possible to maintain a list of names in mvux to update one single name at a time with this 😅

Could be easier for others by this in the future 👍

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[DevTKSS]

@kazo0 I noticed that the PropertySelector Docs are also not connected and would like to quick check with you if this was done on purpose, because honestly I never heared or readed in the Uno Docs about this beeing linked or recommended to be used for something, like we have with the KeyEquality docs here.
Would you please take a look into this and let me know if we might want to re-attach them too and if yes, would you be fine with adding those few changes into this PR or you would prefer a seperate PR for this or you want to do this yourself?

expected changes to add PropertySelector again into the docs:

• doc\toc.ymll: adding 3 lines

• add not existing nested PropertySelector/toc.yml

• doc\Learn\PropertySelector\rules.md: 1 line change

  the namespace used there is Uno.Extensions.Reactive.Rules which is the same uid as doc\Reference\Reactive\rules.md has!
  this could potentially cause docs linking issues if this uid would be used in the future as we are mostly prefering xref linkings over Filepaths. Until now along "Find in Files" VS Code action, we dont use this as xref but could potentially be the case in the future.

[DevTKSS]

🤔 Maybe - just an idea - but would it maybe make more sense to nest them both under a /Core/ section or similar?
The reason I would think this would be a good idea is:
Both of them seem to be defined in Uno.Extensions.Core* and as far as I see, we dont need to add <UnoFeatures> Entries for them.