feat: enhance relation permissions and accessibility checks

[enjeck]

This PR has the following improvements:

• Relation columns can now only link to tables or views you actually have access to, so you can't link to (and expose data from) something you can't see.
• The target picker now hides tables/views you can't read and the table the column lives in, so you only choose valid targets.
• If a linked table or view stops being accessible (e.g. it gets unshared), the relation is automatically disabled and its data hidden, instead of leaking stale information.
• A clear warning now appears on a relation whose target is no longer accessible, telling you to ask for access or pick a different target (right now, the column ID is shown with the warning, but we could just make it empty instead)

• Newly added or edited relation columns show their linked data immediately, without needing a page refresh.

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not needed
• 🔙 Backport requests are created or not needed: /backport to stableX.X
• 📅 Milestone is set
• 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI

[Koc]

@enjeck It's possible to share table/view by share token, you've added it recently #2236. So, after this PR we will not able to join such shared tables

[blizzz]

@enjeck It's possible to share table/view by share token, you've added it recently #2236. So, after this PR we will not able to join such shared tables

Fair. We could simplify and say that columns from publicly shared tables or views can be accessed generally. When they are password protected, however, you would want to verify that and it becomes difficult again. They could be exempted generally though, this would need to come with a clear info somewhere to be an accepted risk. Could still improve upon it later one. Have some stomach aches with this on the one hand, on the other one the relational column can only be added with by a user with sufficient permissions, so it would be OK imo to have that exception.

Or what do other think?

[Koc]

I'm also thinking about adding toggle like that

[Koc]

I'd recommend to merge #2271 first as it introduces very useful method:

$settings = $column->getCustomSettingsObject(RelationLookupSettings::class);
$settings->relationColumnId; // always exists, always non-nullable, so we don't need redundant checks

Also it adds better cache key management buildRelationCacheKey(string $relationType, int $targetId, int $labelColumn): string