[bug]: `network` (project visibility) is silently ignored on create/update via public REST API

[dhuettner]

Describe the bug

The network field (project visibility: 0 = private, 2 = public) is silently ignored by the public REST API, both on project creation (POST) and update (PATCH).

The request succeeds (201 / 200) and the response body echoes the unchanged value. No validation error, no warning. Visibility can only be changed through the web UI.

This means automation cannot provision private projects: every project created via the API is public, and the visibility has to be corrected manually afterwards. In a workspace that contains external members (clients, partners), a newly created project is therefore visible to everyone in the workspace until someone fixes it by hand — which is easy to miss.

Steps to reproduce

1. Create a project with network: 0

curl -X POST "$BASE/api/v1/workspaces/$SLUG/projects/" \
  -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  -d '{"name":"Visibility Test","identifier":"VISTEST","network":0}'

→ 201 Created, but the response contains "network": 2. The project is created public.

2. Try to change an existing project to private

curl -X PATCH "$BASE/api/v1/workspaces/$SLUG/projects/$PROJECT_ID/" \
  -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  -d '{"network":0}'

→ 200 OK, response still contains "network": 2. GET confirms the value is unchanged. Sending "0" as a string behaves identically.

3. Control test — proves the request itself is processed

curl -X PATCH "$BASE/api/v1/workspaces/$SLUG/projects/$PROJECT_ID/" \
  -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  -d '{"description":"changed via API"}'

→ 200 OK, and description is updated. So the endpoint accepts writes; only network is dropped.

Changing the same setting in the UI (Project → Settings → General → Network → Private) works and is immediately reflected in the API response, so the underlying field is writable.

Expected behavior

Either:

1. network is accepted on POST and PATCH via the public API, or
2. the API rejects the request with a clear validation error stating the field is not writable.

Silently discarding a security-relevant field while returning a success status is the problematic part — a client has no way to detect that the project was not created private.

Environment

• Plane Community 1.2.2, self-hosted (Docker)
• Public REST API v1, authenticated with a workspace API key (X-API-Key)
• Reproduced on a workspace where the API key belongs to a workspace Admin

I have not verified whether this is still present in 1.3.1.

Impact / workaround

Workaround is manual: create the project via API, then switch visibility in the UI. That defeats scripted provisioning and leaves a window in which internal projects are visible to all workspace members, including external collaborators or clients who are members of the workspace.