v2.3.1 — the dial_url flag that makes image insertion work

The 403 that blocked add_image_from_dial_url was never a credentials setting. This
release adds the one thing that was missing: a flag in the tool schema.

Why no auth mode could have worked

When the agent calls this toolset, DIAL Core mints a per-request key scoped to
dial-pptx-mcp. That key can read exactly two places:

• Keys/dial-pptx-mcp/ — its own bucket
• Users/{user}/appdata/dial-pptx-mcp/ — its own appdata

A generated image lives in the image deployment's appdata —
Users/{user}/appdata/{image-deployment}/… — which is neither. The toolset call path does
not share conversation attachments onto that key either. So every read of a generated
image was refused, whatever DIAL_AUTH_MODE said.

The bridge

Before each MCP call, Quick Apps scans the tool's input schema and, for every parameter
marked "dial_url": true, asks Core to grant that specific file to the toolset's
per-request key. add_image_from_dial_url never emitted the flag. It does now:

DialFileUrl = Annotated[str, Field(json_schema_extra={"dial_url": True})]

which the pinned SDK passes through to tools/list verbatim:

"image_url": { "dial_url": true, "title": "Image Url", "type": "string" }

Using it

Pass the file URL exactly as received, in image_url. The grant covers the value
Quick Apps saw, so a URL reassembled by hand — or carried in some other argument — is not
granted and still 403s.

A test asserts the flag survives registration to tools/list. It is invisible in normal
use and silently fatal when missing, which is precisely the kind of thing that rots.

The 403 hint added in v2.2.0 now points at the grant rather than at auth mode.

Not flagged

The template tools take a local path or base64/data: content, not a DIAL file URL, so
the flag would grant nothing there. A template-by-URL tool would be a feature, not a fix,
and is not in this release.

Suite is 154 tests, green.