Sort by display value on Person, Relation, Rollup, Files

## Goal

Sort these columns by the string the user reads (display name, related row title, filename), not by the underlying ID.

## Context

#99 shipped sort on `created_at`/`modified_at` but rejected sort on `created_by`/`modified_by`: the stored value is a user ID, and ID-order doesn't match anything visible. Same shape applies to Relation when #109 lands, value-Rollups, and Files.

## Scope

Pick an approach, then apply it consistently:

* JOIN to `wp_users`/`wp_posts` inside `build_query_args`. Cheap, but `display_name` and `post_title` aren't always indexed.
* In-memory sort after fetch. Portable, breaks above one page.
* Custom REST query path per type. Most control, most code.

Apply to `created_by`, `modified_by`, Person, Relation, value-Rollups, Files. Update `validate_sort_field` (`includes/Rest/RowsController.php`) to accept these keys instead of rejecting them.

## Out of scope

* Filtering on these properties (see `tech-debt.md#13`).
* The property types themselves (#109, #116, #117).

## Acceptance criteria

* Sort on `created_by`, `modified_by`, Person columns: alphabetical by display name.
* Sort on Relation columns: alphabetical by related row title.
* Sort on value-Rollup columns: by displayed value.
* Sort on Files columns: alphabetical by filename.
* One sort path covers all four cases, not four type-specific one-offs.

Start with includes/Rest/RowsController.php, especially validate_sort_field, then trace build_query_args and the existing created_at/modified_at sorting from #99. Compare the available approaches and confirm how each in-scope property type exposes its displayed value; done means one shared sort path meets all listed alphabetical or displayed-value acceptance criteria without adding filtering.

Written by the indexing model from the issue text.