Bug: BYOK custom model with noImageSupport:false still has images stripped ([stripImagesFromConversation]) #24

Summary

Droid strips image inputs from requests to a custom BYOK model even though noImageSupport is explicitly false. The docs define this flag as "Set to true to disable image inputs for this model", so false/unset should keep image inputs enabled. Instead, Droid classifies the custom model as non-image and strips images anyway.

Environment

• droid CLI version: v0.205.1
• OS: macOS (Apple Silicon)
• Model configured via customModels in ~/.factory/settings.json

Evidence

The config had previously used noImageSupport: true (in a settings.json.bak0826 backup) and was corrected to false — yet the stripping persisted into sessions well after the change, so a stale-settings explanation is ruled out.

Relevant log line

[stripImagesFromConversation] Stripped images for non-image model with modelId: custom:model, isByok: true

Settings snippet (sanitized)

{
  "model": "model",
  "id": "custom:model-0",
  "baseUrl": "http://127.0.0.1:8317/v1",
  "apiKey": "redacted",
  "displayName": "model",
  "noImageSupport": false,
  "provider": "generic-chat-completion-api"
}

Suspected cause

The model-capability logic (getTuiModelConfig / image-support detection, per the log) appears to classify custom BYOK models as non-image by default and ignore (or fail to re-read) noImageSupport: false for them. Two plausible variants:

1. Capability detection bug: for custom models, Droid only trusts an explicit "image-capable" signal and treats "not flagged as vision" as "no vision" — inverting the documented noImageSupport: false default.
2. Provider quirk: this entry uses "provider": generic-chat-completion-api` (Responses API path).

Expected behavior

With noImageSupport: false (or omitted), Droid should include image_url / image content parts in requests to custom BYOK models, matching the documented semantics of the flag.

Actual behavior

Droid strips images from the conversation before sending, logging [stripImagesFromConversation] Stripped images for non-image model, regardless of noImageSupport: false.

Additional context

• The endpoint itself is reachable and working (earlier 404/empty-response errors on a vision test entry were model-name issues, not image issues), so the stripping is not caused by the backend.