An attachment note can name a library the live session was never granted

[pat-lewczuk]

Follow-up from #957

#957 gives a spawned agent access to the per-project attachment library by passing the library directory to --add-dir. A session's granted directories are fixed when it spawns, and grantableAttachmentLibrary() only grants the directory if it exists at that moment. deliverMessage builds its note with attachmentLibraryHint(persisted) after persistPastedAttachments has just created the library.

So for the first named file attachment ever sent into a project, delivered as a follow-up into an already-running session, the note names .ai/cezar/attachments/ while the agent's granted directories do not include it — the refusal-under---permission-mode dontAsk shape the PR fixed for the spawn path, back on the message path.

From the re-review of 3cce047a:

It is narrow and it costs little: the window is once per project, it self-heals at the next spawn, and this message's own attachments stay reachable because they live under the already-granted runs/. What is lost is the cross-task lookup the library exists for, for one session, plus a wasted refused tool call.

Two ways to close it, either fine: record the granted library on the session state and let attachmentLibraryHint return it only when the session actually has it, or create the library eagerly alongside runs/ so the grant and the mention cannot disagree.

Deferred from #957 deliberately: it is a minor with a one-message blast radius that self-heals, and the fix is a design choice worth making on its own.

Acceptance criteria

• A follow-up message's attachment note never names a directory the live session was not granted — either by tracking the grant on the session, or by creating the library eagerly so grant and mention cannot disagree.
• A test covers the first-attachment-into-a-running-session case: the note and the session's --add-dir set agree.

Related: #957