`posthog_survey` drops `id` from `questions_json` on read, causing "Provider produced inconsistent result after apply"

[Paillat-dev]

Summary

posthog_survey cannot manage a question's id. The PostHog API accepts and
persists an id supplied inside questions_json, but the provider strips it
when reading the resource back, so every apply that declares one fails with
Provider produced inconsistent result after apply.

Environment

• Provider: 1.0.17
• Terraform: v1.15.8
• PostHog: EU Cloud

Reproduction

terraform {
  required_providers {
    posthog = {
      source  = "PostHog/posthog"
      version = "~> 1.0"
    }
  }
}

provider "posthog" {} # POSTHOG_HOST / POSTHOG_API_KEY / POSTHOG_PROJECT_ID from env

resource "posthog_survey" "example" {
  name     = "Question id repro"
  type     = "api"
  schedule = "always"

  questions_json = jsonencode([
    {
      id       = "aaaaaaaa-1111-4111-8111-aaaaaaaaaaaa"
      type     = "open"
      question = "How is it going?"
    }
  ])
}

Then just run terraform apply

Result:

│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to posthog_survey.app_feedback, provider
│ "provider[\"registry.terraform.io/posthog/posthog\"]" produced an
│ unexpected new value: .questions_json: was
│ cty.StringVal("[{\"id\":\"aaaaaaaa-1111-4111-8111-aaaaaaaaaaaa\",\"question\":\"How
│ is SeenShift working for you?\",\"type\":\"open\"}]"), but now
│ cty.StringVal("[{\"question\":\"How is SeenShift working for
│ you?\",\"type\":\"open\"}]").
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

Immediately after the failed apply, reading the survey back shows PostHog
persisted the declared id:

$ curl -s -H "Authorization: Bearer $POSTHOG_API_KEY" \
    "$POSTHOG_HOST/api/projects/$POSTHOG_PROJECT_ID/surveys/" \
  | jq '.results[].questions[] | {id, type, question}'
{
  "id": "aaaaaaaa-1111-4111-8111-aaaaaaaaaaaa",
  "type": "open",
  "question": "How is it going?"
}

Expected

Either of:

1. The provider preserves id when reading questions_json back, so a declared
   question id round-trips and the resource converges; or
2. The provider rejects id in questions_json at plan time with a clear
   error, if managing question ids is deliberately out of scope.