Modals don't work with overridden Model table names

Describe the bug
Loading a modal generates the following PHP error when the model's table name does not follow the default pluralization convention:

Call to a member function getContent() on int
/path/to/app/vendor/orchid/platform/src/Screen/TD.php :286

To Reproduce
Steps to reproduce the behavior:

1. Create a Timeline model and database migration and override the tableName in both to "timeline"
2. Seed the timeline table with some data
3. Create a List panel for the Timeline data with app/Orchid/Screens/Timeline/TimelineListScreen.php and app/Orchid/Layouts/Timeline/TimelineListLayout.php with at least one column to show the data that was seeded
4. Create a layout for a modal for editing the seeded field at app/Orchid/Layouts/Timeline/TimelineEditLayout.php and use the ->render method in TimelineListLayout to load the modal when the value in the table is clicked
5. Click the value in the list to load the modal

Expected behavior
The modal should load the configured fields, so they can be edited.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Pale Moon
• Version: 33.7.2

Server (please complete the following information):

• Platform Version: 14.52.0
• Laravel Version: 12.18.0
• PHP Version: 8.3.22
• Database: MySQL
• Database Version: 8.0.42

Additional context
Looking at the stacktrace, somewhere between the invocation of the editTimelineModal callback in TimelineListScreen::layout and Orchid\Screen\TD->buildTd, what gets passed as the $repository parameter to TD::buildTd gets resolved to an integer 1.

When I clone the database to "timelines" and update string references from "timeline" to "timelines" (Timeline::$table, TimelineListLayout::$target and model/table refs in asyncParameters on TD::make in TimelineListLayout::columns(), TimelineListScreen::query(), TimelineListScreen::loadTimelineOnOpenModal(), and TimelineEditLayout::fields()), the modal loads as expected.

So, it seems to me like there's a bit of code somewhere that's assuming default table naming conventions, even when the custom table name is explicitly set and available in the model and the ListLayout classes; and, when that table doesn't exist, that condition isn't handled.