[Feature]: apply _apply_default_annotations to extra_models so user-added multimodal models are recognized without UI/CLI activation

## Summary
_apply_default_annotations() currently only traverses provider.models (built-in models), skipping provider.extra_models (user-added models). As a result, user-added multimodal models never get their supports_multimodal flag populated at startup, causing tools like view_image / view_video to be silently skipped.

## Component(s) Affected

- [ x ] Core / Backend (app, agents, config, providers, utils, local_models)
- [ ] Console (frontend web UI)
- [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [ ] Skills
- [ ] CLI
- [ ] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Problem / Motivation
When a user adds a model via UI/CLI (add_model()), it is stored in provider.extra_models. On the next startup, _apply_default_annotations() reads capability info from capability_baseline and fills supports_multimodal — but only for provider.models. The extra_models list is never touched.Since get_active_model_supports_multimodal() returns bool(model_info.supports_multimodal), and bool(None) == False, tools gated behind multimodal check are silently dropped from the toolkit even when the model is genuinely multimodal (e.g. qwen3.6-plus).This particularly bites users who activate their model by directly editing the config file and restarting — that path calls load_active_model(), not activate_model(), so maybe_probe_multimodal() is never triggered either. The model is left with supports_multimodal: null indefinitely.

## Proposed Solution
In _apply_default_annotations(), change the traversal to include both provider.models and provider.extra_models:

# Before
for model in provider.models:

# After
all_models = list(provider.models) + list(provider.extra_models)
for model in all_models:

This ensures that any user-added model present in capability_baseline will have its multimodal flags populated at startup, regardless of how the model was activated.

## Alternatives Considered
Call maybe_probe_multimodal() from load_active_model(): This would handle the "config file edit + restart" path, but probe is an async network call (image send) that shouldn't fire unconditionally on startup. It's better as a fallback, not primary path.
Manual config patch: Users can manually set supports_multimodal: true in ~/.copaw.secret/providers/builtin/.json as an immediate workaround, but this is not user-friendly.

## Additional Context
add_model() in provider.py hardcodes target="extra_models" as default — so all user-added models go to extra_models by design.
capability_baseline.py already has entries for common multimodal models (e.g. qwen3.6-plus with expected_image=True, expected_video=True).
The bug means the baseline data exists but is silently ignored for the entire extra_models list.

## Willing to Contribute

- [ x ] I am willing to open a PR for this feature (after discussion).