fix(llm): exclude soft-deleted models from uniqueness check in validateModel (#173)

Closes #169

ModelConfigService.validateModel() flagged a duplicate when re-adding a
manually-typed (provider, modelName) pair that happened to match a row
with deleted=1 in mate_model_config. The user-visible symptom: adding
'dashscope/qwen3-plus' fails with 'model identifier already exists',
yet the management page shows no such model.

The project itself runs hard-delete via deleteById(), so the user-facing
delete path doesn't create deleted=1 rows. The stale rows come from
schema migrations (V44, V81) that intentionally tombstone bogus catalog
entries — for instance V81 sets deleted=1 on the non-existent
'qwen3-plus' (id=1000000172) so it stays out of routing but preserves
the id for audit. ModelConfigEntity has no @TableLogic, and the project
has no global logic-delete-field config, so LambdaQueryWrapper queries
do not auto-append the deleted filter; the migration tombstones leak
into the validate-model query.

Add an explicit .eq(getDeleted, 0) to the uniqueness check so migration
tombstones don't block legitimate re-adds.

Follow-up: several other queries in ModelConfigService share the same
oversight (list/get methods), and a future migration could drop the
tombstones entirely to align with the V20 hard-delete posture.

mateclaw-server/src/main/java/vip/mate/llm/service/ModelConfigService.java

@@ -354,6 +354,7 @@ public class ModelConfigService {
         ModelConfigEntity duplicate = modelConfigMapper.selectOne(new LambdaQueryWrapper<ModelConfigEntity>()
                 .eq(ModelConfigEntity::getProvider, entity.getProvider())
                 .eq(ModelConfigEntity::getModelName, entity.getModelName())
+                .eq(ModelConfigEntity::getDeleted, 0)
                 .ne(currentId != null, ModelConfigEntity::getId, currentId)
                 .last("LIMIT 1"));
         if (duplicate != null) {