[bug]: plane-compose aborts on self-hosted Community edition — work-item-types 404 is not handled like the 402 free-tier case

Describe the bug

On a self-hosted Community edition instance, every plane-compose command that loads the remote project schema (plane pull, plane diff, and by code path plane push / plane validate) fails with:

ERROR    API error 404: Page not found.
Error: Failed to load project schema: list not found. Check your network
connection and API credentials, then retry.

The cause is a mismatch between the status code the code expects and the one Community edition returns.

planecompose/backend/plane.py::_fetch_types already anticipates "this deployment doesn't have work item types" — but it only handles 402:

# Returns empty list on 402 (free tier — work item types not available).
...
except APIError as e:
    if e.status_code == 402:
        logger.warning(
            "Work item types not available on this plan (402) — using empty types list"
        )
        return []
    raise

Plane Cloud's free tier answers 402 Payment Required. A self-hosted Community instance never registers the route at all and answers 404, which falls through to raise and aborts the command.

Confirmed the 404 comes from Plane itself, not from a proxy or CDN:

HTTP/2 404
content-type: application/json
{"error": "Page not found."}

GET /api/v1/workspaces/{slug}/projects/{id}/work-item-types/ — the exact path built by plane-sdk (plane/api/work_item_types.py:89) — 404s for every project in the workspace, while states/, labels/ and members/ all return 200.

Note the CLI also logs Checking workspace_work_item_types feature for omf: False immediately before making the call, so the unavailability is already detected at the workspace level; the project-level fetch happens regardless.

Steps to reproduce

1. Self-host Plane Community edition (v1.4.0).
2. plane auth login with a PAT, plane init a project, plane push the schema.
3. Run plane pull or plane diff.

Result: the command aborts with the error above. plane pull --work-only --no-properties does not avoid it. plane status works, since it doesn't touch the remote schema.

Expected behavior

Treat 404 the same as 402 — a deployment without the work item types API should degrade to an empty types list, not abort. Something like:

if e.status_code in (402, 404):
    logger.warning(
        f"Work item types not available on this deployment ({e.status_code}) "
        "— using empty types list"
    )
    return []

Alternatively, honour the workspace_work_item_types: False result that is already computed and skip the fetch entirely.

Without this, plane-compose is unusable against Community self-hosts for anything beyond plane status.

Environment

• plane-compose 0.5.2, plane-sdk 0.2.21, Python 3.11, macOS
• Plane instance: v1.4.0, edition PLANE_COMMUNITY, self-hosted behind Caddy
• Project has is_issue_type_enabled: false

Start in planecompose/backend/plane.py at _fetch_types and inspect the existing APIError handling for status 402. Reproduce the Community-edition response with plane pull or plane diff, then verify that a 404 for work-item-types produces an empty types list and allows schema commands to continue without the current error.