fix(backend): a failed Hub skill install drops the library skill that resolved to the same name

A failed Hub skill install can still drop a library skill that installed fine, when both resolve to the same name.

hire_expert builds dropped_skills from two sources (backend/api/features/experts/experts_db.py:1104-1111): the names _copy_library_skills reports as failed, and the names of resolved.skills whose attachment is in uninstalled. The uninstalled set is keyed on the whole attachment — (kind, source, id) — and the comment above it says why: "the same slug can be attached from both the Hub and the user's own library, and a failed Hub install must not drop the library copy that succeeded."

The keying decides which names enter the set. The filter that acts on it is still by name:

"skills": [s for s in (expert.skills or []) if s not in dropped_skills]

So when a Hub attachment and a library attachment resolve to the same name, and the Hub one fails, that name enters dropped_skills and the filter removes the successfully copied library skill along with it. The attachment keying prevents the two from being confused on the way in and not on the way out.

The fix is to keep a name when any attachment that resolved to it succeeded — subtract the survivors from dropped_skills before the update, rather than filtering on a set built only from failures. A test: hire an expert with one Hub attachment and one library attachment that resolve to the same name, make the Hub install fail, and assert the name survives on expert.skills.

Found by CodeRabbit while reviewing #14416, outside that PR's diff — the only change it makes to this file is an unrelated active_expert_ids helper, so it is not fixed there.