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

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.

Start with the public REST API v1 project creation and update entry points, reproducing the supplied POST and PATCH requests and comparing the response with a GET. Trace how the network field is handled, then verify that POST and PATCH either apply it correctly or return a clear validation error without silently succeeding.