Return 404 when fetching an unset displayname or avatar_url

[barodeur]

⚠️ This change is not backward compatible. Not sure yet what's the best way to handle this.

GET /_matrix/client/v3/profile/{userId}/displayname (likewise avatar_url) returned 200 {"displayname": null} when the field is unset, where the spec documents a 404 for a profile key that does not exist. Custom fields on the same endpoint already 404 correctly, so built-in and custom keys behaved differently on the same route:

Before:

GET /_matrix/client/v3/profile/@alice:example.com/avatar_url   (no avatar set)
→ 200 {"avatar_url": null}

After:

GET /_matrix/client/v3/profile/@alice:example.com/avatar_url   (no avatar set)
→ 404 {"errcode": "M_NOT_FOUND", "error": "Profile was not found"}

This is not hypothetical: the 200-with-null shape already breaks spec-compliant clients — ruma's get_profile_field fails to deserialize {"avatar_url": null} (ruma/ruma#2360), affecting Element X, and matrix-rust-sdk carries workarounds for it (matrix-org/matrix-rust-sdk#6148, matrix-org/matrix-rust-sdk#6883).

Backward compatibility

⚠️ not sure how to handle this backward incompatible change. Checking matrix-rust-sdk at current main against this change:

• Account::get_display_name improves: today an unset displayname fails deserialization (get_profile_field doesn't handle null in the response. ruma/ruma#2360); with this change it receives the 404 that the SDK already documents as the expected server response.
• Account::get_avatar_url regresses: the workaround from matrix-org/matrix-rust-sdk#6148 uses the legacy endpoint and relies on 200 {"avatar_url": null} → Ok(None); it does not handle M_NOT_FOUND, so an unset avatar would start returning an error until the SDK maps the 404 to None (as suggested in the get_profile_field doesn't handle null in the response. ruma/ruma#2360 thread).
• The full-profile endpoint (GET /profile/{userId}) path is unaffected.

Fixes #13137. Related: #19466 (this addresses the GET inconsistency reported there; the PUT-with-empty-string behaviour is out of scope).

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Code style is correct (run the linters)