Use single sharding key note fixtures in specs

What does this MR do and why?

Rework note spec fixtures that persist more than one sharding key (project_id plus namespace_id or organization_id) into realistic single-key setups:

• Group-level notes where a note namespace_id is the subject under test (note_metadata_spec, mentionable_spec, model_with_associated_note shared examples) — assigned in memory where a transient value is sufficient.
• Personal snippet notes for organization-keyed cases (editable_spec, spec/frontend/fixtures/snippet.rb).
• Single-keyed vulnerability notes in the restore_incorrect_vulnerability_states BBM spec (project-scoped notes carry only project_id).
• Skip the project-path outdated_line_change_path assertion for group-scoped notes, which have no project (note_entity shared examples).

Why

Every notes row is moving to exactly one sharding key (project_id XOR namespace_id XOR organization_id), enforced by a NOT VALID check constraint queued in !238033 (merged) together with the cleanup BBM.

These fixtures currently persist dual-keyed notes, which would violate that constraint. Updating them ahead of time:

• keeps !238033 (merged) focused on the migration, BBM, and model changes, and
• makes these specs describe the intended data shape rather than a legacy state that is being cleaned up.

All examples pass on master today — the fixtures are behavior-neutral for the current schema.

Part of #569520

How to set up and validate locally

bundle exec rspec spec/models/notes/note_metadata_spec.rb \
  spec/models/concerns/editable_spec.rb \
  spec/models/concerns/mentionable_spec.rb \
  spec/models/diff_note_position_spec.rb \
  spec/models/note_diff_file_spec.rb \
  spec/models/suggestion_spec.rb \
  spec/models/user_mentions/commit_user_mention_spec.rb \
  ee/spec/serializers/epic_note_entity_spec.rb \
  ee/spec/lib/ee/gitlab/background_migration/restore_incorrect_vulnerability_states_spec.rb