fix(providers): order the attachment failure reason by how general the cause is

The generated-document arm was checked first, so it won over both other causes
and told users two things that were not true.

On an inline-strategy provider — bedrock, mistral, ollama, fireworks, litellm,
vertex, kimi — there is no upload path for any file, generated or not, but the
message blamed the document format and implied a plain PDF would go through.

On openai or google with cloud storage unconfigured it was simply false: a
generated document does take the Files API path there, and that exact file
uploads fine once storage exists. The one actionable fix was hidden from the
operator.

A provider with no upload path cannot be helped by changing the file, and a
deployment with no object storage cannot reach any upload path whatever the
file is, so both now outrank the format-specific case — which is left saying
only what is true of it: a signed URL points at the generation source rather
than the rendered file.

The formatter is unchanged. It was brute-forced over every real ceiling and
three million random pairs with no collision or inversion, but the test's six
ceilings all divide to exact integers, so floor, round and ceil are
indistinguishable on them and the limit-side rounding was unpinned. A ceiling
with a fractional remainder now covers it.

Author: waleedlatif1

apps/sim/executor/handlers/agent/agent-handler.ts

@@ -15,7 +15,6 @@ import {
   SIM_AUTO_SYSTEM_PREAMBLE,
 } from '@/lib/model-router/resolve'
 import {
-  isGeneratedDocumentSourceType,
   MODEL_SUPPORTED_IMAGE_MIME_TYPES,
   processFilesToUserFiles,
   type RawFileInput,
@@ -985,11 +984,19 @@ export class AgentBlockHandler implements BlockHandler {
           inlineMaxBytes
         )
         const oversized = Number.isFinite(missingFile.size) && missingFile.size > inlineMaxBytes
-        const reason = isGeneratedDocumentSourceType(missingFile.type)
-          ? `a generated document cannot use the large-file path for provider "${providerId}"`
-          : getProviderFileStrategy(providerId) === 'inline'
+        /**
+         * Ordered by how general the cause is. A provider with no upload path at all cannot be
+         * helped by changing the file, and a deployment with no object storage cannot reach any
+         * upload path whatever the file is — so both outrank the format-specific case. Leading
+         * with the generated-document arm blamed the document on providers that have no upload
+         * path for anything, and on hosts whose only real problem was unconfigured storage.
+         */
+        const reason =
+          getProviderFileStrategy(providerId) === 'inline'
             ? `provider "${providerId}" has no large-file upload path`
-            : 'this deployment has no cloud file storage for the large-file upload path'
+            : !canUseProviderLargeFilePath(providerId)
+              ? 'this deployment has no cloud file storage for the large-file upload path'
+              : `a generated document cannot use the large-file path for provider "${providerId}", because a signed URL points at the generation source rather than the rendered file`
         throw new Error(
           oversized
             ? `File "${missingFile.name}" (${sizeMB}MB) exceeds the ${inlineMB}MB inline attachment limit, and ${reason}.`

apps/sim/providers/attachments.test.ts

@@ -321,6 +321,13 @@ describe('attachment limit formatting', () => {
       const justOver = formatAttachmentSizes(limit + 1, limit)
       expect(justOver.size).not.toBe(justOver.limit)
     }
+
+    /**
+     * Every ceiling above divides to an exact integer, so floor/round/ceil are indistinguishable
+     * on them — only a ceiling with a fractional remainder pins the limit-side rounding.
+     */
+    const fractional = formatAttachmentSizes(12_345_679, 12_345_678)
+    expect(fractional.size).not.toBe(fractional.limit)
   })
 
   it('keeps a comfortably over-limit size readable', () => {