getOrgs declares a 204 the provider cannot emit, and a bodiless 204 makes 'no organizations' indistinguishable from a failed fetch

[CodeAhmedJamil]

Summary

getOrgs (schemas/constructs/v1beta2/organization/api.yml) declares a "204": No content response that the provider - Layer5 Cloud, server/handlers/organizations.go - cannot emit, and should not.

Why it cannot be emitted

The handler's only 204 was behind err.Error() == sql.ErrNoRows.Error(). The DAO never returns that: OrganizationDAO.GetOrganizations wrapped its zero-row case in a MeshKit error (ErrNoOrgExistForUser), whose Error() is the MeshKit-rendered message and never equals the sentinel's "sql: no rows in result set". The branch was dead from the moment it was written; the real answer for a zero-row page was the 500 below it.

Why it should not be re-enabled

A 204 has no body, so a client cannot distinguish it from a failed request. That is exactly the defect filed as layer5io/meshery-cloud#5921: the Create Workspace / Create Environment organization picker could not tell "you belong to no organizations" from "the organizations fetch failed", and rendered both as an empty select with a dead Save.

Layer5 Cloud now answers an empty list as 200 with the declared OrganizationsPage envelope - {"organizations": [], "page": 0, "pageSize": N, "totalCount": 0} - which is the shape every consumer already handles (layer5io/meshery-cloud#5920 / #5921 fix).

Requested change

Drop the "204" response from getOrgs. 200 with an empty organizations array is the complete contract for an empty result.

Note for consumers

No generated-client change is expected: GetOrgsApiResponse is already typed from the 200 schema alone, and organizations is already optional.