v2.1.0 — accept every DIAL file link form

add_image_from_dial_url now accepts the file links DIAL actually hands out.

The bug

An image deployment returns its result as a link like

https://<dial-host>/api/files/{bucket}/appdata/<model>/images/<hash>.png

DialFileClient.download understood only the relative files/{bucket}/{path} form and
its own /v1/files/... URL. Anything else was appended to the base URL wholesale, so the
chat frontend's proxy path turned into /v1/files/api/files/... and 404'd — the one link
shape an orchestrator is most likely to have.

The fix

_file_request_url normalizes every DIAL file reference — relative or absolute,
v1/files/... or api/files/... — and always rebuilds the request against
DIAL_CORE_URL. A link's host is therefore only ever an authorization question, never
where the bytes come from.

New DIAL_PUBLIC_URL (comma-separated URLs or hostnames) lists this installation's public
aliases, for the common deployment where the server reaches Core in-cluster while the
orchestrator holds https://chat.example.com/api/files/... links.

Better refusals

Foreign hosts are still refused — an MCP tool that fetches arbitrary URLs is an SSRF
primitive, and that will not change. But the refusal now names the host and tells the
agent what to do instead:

Refusing to download from upload.wikimedia.org: this server reads files from DIAL file
storage only, never arbitrary web URLs. Save the file to DIAL file storage first and
pass the 'files/{bucket}/{path}' URL that upload returned.

The old message — "Refusing to download from a host other than DIAL_CORE_URL." — gave a
model that had just passed a wikipedia.org URL nothing to act on. The tool description now
states the same rule up front, so the orchestrator should not try in the first place.

The reference is also validated before credentials are resolved: a bad URL is reported
as a bad URL instead of as a missing API key.

Suite is 144 tests, green.