Feature: Reach the files area, and attach a file more than once

[CFDan]

Stacked on #489 — review that first. Base is feature/create-upload-url, so this diff shows
only the files-area work.

Why

Chasing the customer's upload complaint turned up two gaps behind it.

Nothing calls projects.FileCreate. A file could only ever arrive in a project's files
area as a side effect of being attached to a task, comment or message. There was no way to
store one on its own, or to give it a description, category or tags. twprojects-create_file
is named for this and does something else — it produces a pending reference.

A pending reference is spent by the first attachment, and the files area is the only
route to an identifier that is not. But parseTaskAttachments filled
TaskAttachments.PendingFiles and never .Files, so nothing could consume one. A single
document belonging to three tasks had to be uploaded three times.

That second one is the customer's actual use case — one insurance certificate referenced
from several tasks — even though it is not what they filed.

What

twprojects-add_project_file {project_id, reference, …} stores an uploaded file in a
project's files area and answers with its ID.

attachment_file_ids on create_task and update_task accepts those IDs alongside
attachment_refs.

Why two parameters rather than one that takes either: they are not interchangeable —
one is spent by the first attachment and the other is not — and telling them apart by the
tf_ prefix would encode a guess about the identifier format that the SDK itself declines
to make (it never parses or constructs that prefix).

Verification

go build ./... && go vet ./... && go test ./... all pass; docs regenerated.

Per AGENTS.md, the mocks reply the same either way, so the tests assert on the encoded
body rather than on the call succeeding: pendingFileRef and the optional fields reach the
POST /projects/{id}/files.json body, and both attachment forms survive together on a task.

TestTaskAttachmentsOmittedWithoutEither is the regression guard — adding a second
parameter must not start sending an empty attachments object on every task. The
pre-existing TestTaskAttachmentsOmittedWhenNotRequested in the SDK still passes too.

Token cost, per go run ./cmd/mcp-tokens -base=main: +665 for this PR (+982 for the
stack). add_project_file +499, and +83 each on create_task/update_task.

Open questions for you, @rafaeljusto

1. Was .Files left out deliberately? You restricted comments to pending refs only for
   a stated reason (the endpoint takes nothing else). If the task .Files omission was also
   deliberate rather than incidental, say so and I will drop that half — I could not tell
   from the code which it was.
2. Naming. create_file produces a reference, add_project_file consumes one. I avoided
   renaming create_file because it is shipped and clients depend on it, and instead
   rewrote its description to say what it actually returns. Still not lovely.
3. Messages are deliberately untouched. MessageCreateRequest.Attachments is a
   LegacyNumericList that would take file IDs the same way, but that is outside the three
   flows this work was scoped to, so it is a follow-up rather than a quiet widening.

🤖 Generated with Claude Code

[rafaeljusto]

Working as expected!

twprojects-add_project_file

{
  "name": "another-test.txt",
  "project_id": 6,
  "reference": "tf_b4a009bc-9a89-46bd-a60c-609ba2fd6437.txt"
}

twprojects-create_task

{
  "attachment_file_ids": [
    2
  ],
  "name": "Task 6",
  "tasklist_id": 5
}