[Studio][Bug] Deleting an instance leaves cached data-source bindings stale

## Problem

After #4049, SettingsService caches both full and paged data-source inventories in the shared data-sources cache. InstanceService.deleteInstance removes the deleted instance name from DataSourceVO.instanceIds by writing through SettingsRepository directly, so none of SettingsService's cache-eviction write paths run.

The database row is updated, but cached list results can keep exposing the deleted binding until another data-source mutation or application restart.

## Reproduction

1. Create a data source bound to instance-a.
2. Call the full or paged data-source list endpoint to populate its cache.
3. Delete instance-a.
4. Query the same data-source list again.

The repository no longer contains instance-a in the binding, while the cached response can still contain it.

## Expected behavior

A successful instance deletion should invalidate the shared data-source cache after the deletion transaction commits. A failed or rolled-back deletion should leave the existing cache untouched.

## Scope

This issue only covers cache invalidation for the cross-service data-source binding update performed during instance deletion.

Start with InstanceService.deleteInstance and the SettingsService cache-eviction write paths, then inspect how SettingsRepository updates the data-source binding. Reproduce the full or paged data-source list flow, and verify that a successful deletion clears cached results after commit while a failed or rolled-back deletion preserves them.

Written by the indexing model from the issue text.