docs: correct the stale AI provisioning comments and record the list-folders decision

[Adron]

Summary

Closes #39. Records the owner decision on #49 (which stays open by design).

Two pieces of bookkeeping, both about the same failure mode: a conclusion that was reached, acted on, and then left only in code comments or an issue thread — where the next parity sweep re-derives the wrong answer.

1. The AI copy was fixed; the code around it still argued the opposite (#39)

PR #83 fixed the user-facing string — it no longer tells subscribers to "add your own AI provider key", a setting that does not exist. But five surrounding comments still describe the disproved model:

"AI is gated on two things the server owns: an active subscription and a provider key the user supplied on the web Integrations page."

"every run costs the user money — a quota unit and a call against their own provider key"

"Shown next to a preview so the cost of the user's own provider key is visible"

A correct string surrounded by comments asserting the opposite is how the wrong copy gets written back. Corrected against a live probe on a subscriber account:

GET /api/ai/status → 200 {"subscriber":true,"providers":["anthropic"],
                          "defaultModels":{"anthropic":"claude-sonnet-5",…},
                          "quota":{"usedToday":0,"dailyLimit":50,"remaining":50}}

AI is powered by Claude and provided by InterlinedList as part of the subscription. Two things follow, and both are now written down where the next reader will hit them:

• The scarce resource is quota, not money. 50 a day on the probed account. That is what the "every run costs something" rule is protecting, and the comment now says so.
• An empty providers[] is a service outage, not a user misconfiguration — which is why the copy must not ask the user to fix it.

2. The list-folders decision lived only in an issue comment (#49)

#49's own acceptance criterion was "a decision is recorded in docs/decisions/, whichever way it goes". The owner decided on 2026-09-13 and recorded it as an issue comment. Now written up as docs/decisions/0007-list-folders-not-returning-to-macos.md, including the two consequences that are easiest to lose:

• The capability gate ships 11 Feature cases, not 12. .listFolderCreation was dropped before PR feat(gating): land the capability gate and reconcile it with G22-G25 #83 merged. A gate for a capability the client does not have is dead code that reads like a promise.
• A list's folderId is preserved, not managed. A list filed into a folder on the web must stay filed there after a macOS edit. That holds by construction today — UpdateListRequest carries no folderId — and anything that adds one has to keep it.

The doc also nails down the two things a sweep keeps re-conflating: parent/child list nesting is a different feature and was never removed, and issue #28 was about a leftover control, not the absent feature.

#49 stays open, labelled wontfix, as the standing product record — closing it would make the divergence read as an oversight again, which is the exact failure the decision exists to prevent.

Verification

• xcodebuild build → ** BUILD SUCCEEDED **
• xcodebuild test (App) → Executed 968 tests, with 0 failures · ** TEST SUCCEEDED **
• swift test InterlinedDomain → Executed 1012 tests, with 0 failures
• swift test InterlinedPersistence → Executed 140 tests, with 0 failures

No behaviour changes — comments, one new decision doc.

🤖 Generated with Claude Code

https://claude.ai/code/session_016gSWb3scYobtxLJioV1qF9