Add optional org_id filter to ListProjectsByUser

Inizia dal punto di ingresso ListProjectsByUser in internal/api/v1beta1connect/user.go e dalla definizione della request corrispondente in raystack/proton. Traccia come il core/project.Filter esistente riceve il Principal dell’utente, quindi replica la gestione di org_id di ListProjectsByCurrentUser. Il lavoro è completato quando un org_id non impostato o vuoto mantiene i risultati attuali e un valore impostato limita i risultati a quell’organizzazione.

Is your feature request related to a problem? Please describe.
FrontierService.ListProjectsByUser returns every project a user has access to across all organizations, with no way to scope the result to one organization server-side. The request message only carries the user id:

message ListProjectsByUserRequest {
  string id = 1;
}

Callers that need "projects of user X within org Y" (a common multi-tenant lookup) have to fetch all of the user's projects and filter by org_id client-side. The sibling RPC ListProjectsByCurrentUser already supports exactly this filter, so the two contracts are inconsistent:

message ListProjectsByCurrentUserRequest {
  // org_id is optional and filter projects by org
  string org_id = 1;
  ...
}

Describe the solution you'd like
Add an optional org_id filter to the request, mirroring ListProjectsByCurrentUserRequest:

message ListProjectsByUserRequest {
  string id = 1;
  // org_id is optional and filters projects by org
  string org_id = 2;
}

Semantics:

• org_id unset/empty → current behavior unchanged (projects across all orgs), so the change is fully backward compatible on the wire and in behavior.
• org_id set → only projects belonging to that organization are returned.

The implementation looks small: the handler (internal/api/v1beta1connect/user.go → ListProjectsByUser) already builds a core/project.Filter, which supports OrgID alongside Principal — the new field just needs to be passed through, plus the proto change in raystack/proton.

Describe alternatives we've considered

• Client-side filtering of the full ListProjectsByUser response by project.org_id — works, but transfers and transforms all projects across every org the user belongs to on each call.
• ListProjectsByCurrentUser with org_id — only works for the authenticated user; it can't be used by a service user resolving another user's projects.
• ListOrganizationProjects — scoped to the org but not filterable by user, so it would require intersecting two full listings client-side.

Additional context
We call this RPC from a backend service (service-user credentials) via the Go SDK (frontierv1beta1.ListProjectsByUserRequest) to resolve the projects a given user can access within one specific organization.