Extend useSortedInterfaceMembers to object type literals

[finnan444]

useSortedInterfaceMembers only matches TsInterfaceDeclaration, so codebases that describe their public contracts as type aliases get nothing out of it:

// sorted by the rule
interface Env { b: number; a: string }

// ignored
type Env = { b: number; a: string }

I couldn't find a documented reason for the limitation. Type aliases don't come up in #7553 or #8164, and there's no open issue about it, so it looks incidental rather than deliberate.

The implementation side is small. TsObjectType is '{' members: TsTypeMemberList '}', TsInterfaceDeclaration holds the same TsTypeMemberList, and those are the only two nodes in the grammar that hold one. Sorting, the sortable/non-sortable split for call/construct/index signatures, comment preservation and the partitionByNewLine sectioning all work on the list alone, so they carry over unchanged.

What changes is the query node: either Ast<TsTypeMemberList> or a declare_node_union! of the interface and TsObjectType. I'd go with the union, since querying the list directly moves the diagnostic range from the interface node to the member list and churns the existing snapshots for no reason.

Two things I'd rather not decide on my own.

The name. useSortedInterfaceMembers stops describing what the rule does. As I see it: keep the name and clarify the docs, rename to useSortedTypeMembers with the old name as a deprecated alias, or add a separate rule for type literals. I'd pick the first as the least invasive, though it does leave a name that lies a bit.

The scope. Only type X = { ... } at the top level, or every TsObjectType, including nested ones, function parameters, type arguments and intersections like A & { ... }? I lean towards every TsObjectType: it's uniform, and it's actually less code, because restricting to top-level aliases needs an extra ancestor check. The trade-off is a noticeably wider autofix surface.

TsMappedType is a separate node either way, so { [K in T]: V } stays untouched.

If both get settled, I'll send the PR against next, since that's where #10424 landed and the rule there already has the partitionByNewLine plumbing.

Disclosure: this write-up was drafted with Claude Code; the grammar and implementation details in it were checked against the code.