tech debt: remove April-2017 backwards-compat branch in NamespaceTypeAdapter

[chrisdebian]

Summary

wikidata/json/NamespaceTypeAdapter.kt contains a backwards-compatibility branch that was explicitly marked for removal in 2017:

// Prior to 3210ce44, we marshaled Namespace as the name string of the enum, instead of
// the code number. This introduces a backwards-compatible check for the string value.
// TODO: remove after April 2017, when all older namespaces have been deserialized.
if (reader.peek() == JsonToken.STRING) {
    return Namespace.valueOf(reader.nextString())
}
return Namespace.of(reader.nextInt())

The comment is now 9 years overdue. Any Namespace data serialized before commit 3210ce44 would have been deserialized and re-serialized many times since then, and will now be in the current integer format.

Proposed fix

Remove the STRING branch, leaving only:

return Namespace.of(reader.nextInt())

Before raising a PR

I'd like to confirm:

1. Is there any known code path that could still produce a string-encoded Namespace today (e.g. old cached data on device, API response, test fixture)?
2. Is Namespace.of(int) the only deserialization path we need after the removal?

Happy to raise a PR once these are confirmed. Thanks — Chris

[chrisdebian]

PR raised: #6893

Confirmed safe to remove after reading the code — has always emitted integers, no test fixture uses the STRING path, and 9 years of app updates will have converted any old data. Added a dedicated unit test for the adapter as part of the cleanup.