twprojects-create_comment cannot post private comments

[thejimbirch]

Summary

The Projects comment tool (twprojects-create_comment, and twprojects-update_comment) provides no way to mark a comment private. Teamwork's product supports comment privacy, and the Spaces side of this repo already exposes it (twspaces-create_comment has an isPrivate param — internal/twspaces/comments.go:152), but the Projects equivalent never got it.

This blocks a common workflow: keeping development/internal comments private until they're ready for a client to review.

Current state

Privacy is absent at two layers:

• MCP tool — internal/twprojects/comments.go exposes only object, body, content_type, notify_current_user, notify.
• SDK — projects.CommentCreateRequest / CommentUpdateRequest (teamwork/twapi-go-sdk) carry only Body, ContentType, NotifyCurrentUser, Notify, so the typed struct the tool marshals can't carry a privacy flag.
• API — CommentCreate POSTs to the v1 endpoint /{resource}/{id}/comments.json with {"comment":{…}}. The v1 comment object carries a private field, and the product supports choosing who a comment is private to (support docs), so the capability exists in the API — it's just not surfaced.

Proposed change

Prerequisite — SDK (teamwork/twapi-go-sdk):

• Confirm the exact v1 param (historically isprivate 0/1; verify whether privacy also accepts a user/company-ID recipient list).
• Add the field(s) to CommentCreateRequest and CommentUpdateRequest with omitempty.
• Add SDK tests; tag a release; bump go.mod in this repo.

This repo (internal/twprojects/comments.go):

• Add a private param to CommentCreate's InputSchema, mirroring the twspaces isPrivate style (AnyOf: [boolean, null]). If the API supports targeted recipients, model that with the existing helpers.UserGroupsSchema pattern already used for notify.
• Wire it through the handler via helpers.OptionalPointerParam.
• Mirror on CommentUpdate.
• Update the tool description to mention privacy.
• Add tests in comments_test.go asserting the privacy field serializes into the request body (using the existing mcpServerMock/toolRequest helpers).

Notes

The MCP tool change is blocked on the SDK release. An alternative that avoids the SDK dependency — having the handler POST a raw request body directly — was considered but rejected as it runs against the repo's typed-SDK conventions.

[rafaeljusto]

Thank you for the detailed request @thejimbirch ! I've added it to our backlog, and we will be working on it soon.