Limit a queries select to the model's table

Describe the bug

I have the following type:

type User @modelClass(class: "App\\Models\\User") {
    id: ID!
    donations(
        type: String = "charge" @where(key: "donations.type")
        status: String = "complete" @where(key: "donations.status")
        teamId: ID @scope(name: "byTeam")
    ): [Donation!]
        @hasMany(type: "connection")
}

User.donations is a hasManyThrough relationship. So in order to limit by teamId an additional join is applied during the scope:

    public function scopeByTeam(Builder $query, int $teamId): Builder
    {
        $table = $this->getTable();

        $query
            ->join('campaigns', "$table.campaign_id", '=', 'campaigns.id')
            ->where('campaigns.team_id', '=', $teamId);

        return $query;
    }

This is where things break. The resulting donations have much of the correct data but the wrong ID. The reason for this is actually pretty simple. By default selects in Laravel are *, which means that all columns including the joined table columns are included. Since the joined table also has an ID column and it comes later in the results the ID of the joined table item is returned instead of the correct table's ID.

Expected behavior/Solution

Since Lighthouse has the model and is building the query, all we should really need to do here is to apply the table to the query select. Something like $query->select("{$model->getTable()}.*").

I don't believe this would cause backwards-incompatibility as the GraphQL object is expecting to only be a single model, anyway. The only scenarios I'm not sure of is how Lighthouse handles sub-models and eager loading.

Environment

Lighthouse Version: 5.9
Laravel Version: 6.x

Start by tracing the hasManyThrough relationship and the @hasMany(type: "connection") query path described in the issue, then inspect how the model and scopeByTeam join affect the selected columns. The change is done when joined columns no longer overwrite the model's attributes, especially its ID, while the relationship and eager-loading behavior still work.