Add extendTable support to relation-style admin pages

[tazzytazzy]

This PR implements Ask 1 from #2448 by adding an extendTable seam to relation-style resource pages in Lunar admin.

Today, packages can extend resource tables and relation-manager tables through narrow hooks, but relation-style pages built on BaseManageRelatedRecords do not expose the same seam. That forces packages to replace an entire page just to adjust one column, action, filter, or query clause.

This change brings those pages in line with Lunar's existing extension pattern.

What changed

New base table seam for relation-style pages

BaseManageRelatedRecords now uses a new ExtendsTables concern.

That concern provides the same shape Lunar already uses elsewhere:

public function table(Table $table): Table
{
    return $this->callLunarHook('extendTable', $this->getDefaultTable($table));
}

protected function getDefaultTable(Table $table): Table
{
    return $table;
}

Typed hook on RelationPageExtension

RelationPageExtension now exposes:

public function extendTable(Table $table): Table
{
    return $table;
}

This makes the relation-page table seam discoverable and consistent with the existing resource and relation-manager extension APIs.

Existing page table definitions moved behind getDefaultTable()

Each BaseManageRelatedRecords subclass that previously owned its own table definition now moves that table-building logic into getDefaultTable().

The touched pages are:

• ManageUrlsRelatedRecords
• ManageCollectionProducts
• ManageCollectionChildren
• ManageProductVariants
• ManageProductCollections
• ManageProductAssociations
• ManageVariantMedia
• ManageBrandProducts
• ManageBrandCollections

Compatibility note

The touched pages keep a thin public table() wrapper that delegates to the new base implementation:

public function table(Table $table): Table
{
    return parent::table($table);
}

Behaviorally, this is redundant, but it preserves the concrete-class table() method shape for any downstream code that may reflect on those page classes directly, such as other add-ons.

Why this approach

This keeps the change narrow and upstream-safe:

• no page replacement required for simple table customization
• no image handler specific logic
• no media adapter work
• no Ask 2 / Ask 3 changes from Proposal: add a few small Lunar admin extension seams for custom media systems #2448
• default behavior remains unchanged when no extension is registered

Tests

Added focused coverage around a real relation-style page, ManageCollectionProducts, to verify:

• the concrete page still exposes a public table() method
• default table behavior is unchanged when no extension is registered
• a RelationPageExtension can extend the table by adding a column

Verification

Ran:

• vendor/bin/pint --dirty --format agent
• vendor/bin/pest tests/admin/Feature/Support/Extending/RelationPageExtensionTest.php

Notes

ManageProductVariants also had an unreachable dead block in its old table() method after an early return $table;. That dead code was removed as part of moving to getDefaultTable(), with no intended behavior change.