Variable behavior in accessing service plans in v2 depending on endpoint

Issue

Variable behavior in accessing service plans in v2 depending on endpoint

Steps to Reproduce

1. Target space alice
2. Enable a service offering. This should create a service plan. Lets call this plan bob.
3. Create a service instance of bob
4. Change the visibility of bob to public: false
5. Log in as a space dev
6. query /v2/service_plans | [grep bob.guid] and get no results
7. query /v2/spaces/[alice.guid]/summary and get:

cf curl /v2/spaces/33666dbb-0bcb-4372-8078-0c53746072c0/summary
{
  "guid": "33666dbb-0bcb-4372-8078-0c53746072c0",
  "name": "alice",
  "services": [
    {
      "guid": "8648f264-9a45-40a7-b31f-6538eb0f9f2c",
      "name": "bob's service offering",
      ...
      "service_plan": {
        "guid": "ba65e2e1-a784-44cd-9da6-2145bb9297e1",
        "name": "bob",
        "maintenance_info": {
          "version": "1.0.0"
        },
      }
    }
  ]
}

8. query /v2/service_plans/[bob.guid] and see bob

Current behavior

In the services list endpoint we are not able to see bob
in the service get and space summary endpoints we are able to see bob

Expected behavior

I would argue that theres no security risk allowing space devs to read service plans that are being used in the space. I would like to see v2/service_plans show bob.

Reproduce the discrepancy using /v2/service_plans, /v2/service_plans/[bob.guid], and /v2/spaces/[alice.guid]/summary with a private plan used in the space. Trace the endpoint authorization and visibility filtering, then make the service-plans list behavior consistent with the expected access for space developers. Confirm the result with endpoint-level tests covering private plans in use.