Mark project_topic_upload_states as needing no transfer work

Topics are not moved between organizations. Organizations::Transfer::TopicsService re-creates each topic in the new organization and TransferTopicAvatarWorker copies the avatar onto the new topic, which creates a fresh project_topic_uploads row there. The project_topic_upload_states row for that upload gets its organization_id from the upload through trigger_b04dea279493, and the source topic keeps its own upload and state row in the old organization.

project_topic_uploads is already registered as no_work_needed for exactly this reason, so the state table needs nothing either. This MR sets the registry entry accordingly and adds an EE spec on TransferTopicAvatarWorker that pins the behaviour down: the copied avatar's state row is created in the new organization and the source state row is left alone.

Resolves #616255

Differences

Before: project_topic_upload_states is listed with a tracking issue URL, implying missing transfer logic.

After: It is listed as no_work_needed, and a spec proves the trigger-based derivation that makes that true.

How to set up and validate locally:

1. bundle exec rspec ee/spec/workers/organizations/transfer_topic_avatar_worker_spec.rb
2. bundle exec rspec spec/lib/gitlab/organizations/organization_transfer_support_spec.rb