Nil Pointer Dereference in Watcher Executor -> dereference panic.

Nobody has claimed this yet.

### Describe the bug

### Diagram
```mermaid
sequenceDiagram
participant Watcher
participant Executor
participant Client as connectors.NewClient
Watcher->>Executor: TriggerImport(entry)
Executor->>Client: NewClient(*globalClientOpts)
Note over Client: Fails (e.g. invalid context)
Client-->>Executor: nil, err
Note over Executor: Logs error, but DOES NOT return!
Executor->>Executor: mc.UploadArtifact(entry.FilePath, entry.MainArtifact)
Note over Executor: Panic: nil pointer dereference (mc is nil)
```

### Description
In `pkg/watcher/executor.go`, the `TriggerImport` function instantiates the Microcks client using `connectors.NewClient`. If this fails (e.g., due to an invalid context or server address), it prints an error message but continues execution instead of returning early. It subsequently calls `mc.UploadArtifact()`, causing a nil pointer dereference panic.

### Impact
The watcher daemon crashes with a stack trace instead of handling the connection/context resolution failure gracefully.

### Steps to Reproduce
1. Configure a watch entry with an invalid or expired context.
2. Modify the watched file to trigger an fsnotify event.
3. The watch manager invokes `TriggerImport`, which prints `[ERROR] Cannot connect to Microcks client...` and immediately panics with a segmentation fault.

---

Read pkg/watcher/executor.go and start at TriggerImport, following the connectors.NewClient error path before mc.UploadArtifact is called. Reproduce the issue with an invalid or expired context and a watched-file change, then verify the watcher handles the client failure without a nil-pointer panic.

Written by the indexing model from the issue text.