Draft: Move Ruby language helpers into gitlab-platform-core

What does this MR do and why?

Gitlab::AbstractMethodError, Gitlab::Lazy and Gitlab::ClassAttributes depend on nothing but Ruby and, for one of them, ActiveSupport. They carry no GitLab domain knowledge, which makes them safe to move into gems/gitlab-platform-core as pure renames, same as the previous seven files.

class_attributes.rb now has an explicit require 'active_support/concern', which it previously got for free from the Rails boot. The other two files need no requires. Gitlab::ClassAttributes is included at class-definition time by app/workers/concerns/worker_attributes.rb, lib/gitlab/endpoint_attributes.rb, lib/bulk_imports/pipeline.rb and several Gitlab::Database mixins. This keeps working because the gem is required from config/application.rb before Zeitwerk initialises, so the constants exist before any consumer is autoloaded. Verified with bin/rails zeitwerk:check and by confirming a real worker still resolves its declared attributes. The RSpec/VerifiedDoubles exclusion for lazy_spec.rb moves into the gem's .rubocop.yml; the .rubocop_todo/ entries for Gitlab/NamespacedClass, RSpec/FeatureCategory and Style/InlineDisableAnnotation are just pruned, since those cops are already off for in-repo gems via gems/config/rubocop.yml.

Context

Part of #635231, which has the plan, verification and risks for this workstream. The tracking issue for the whole slice is #632651.

This MR is stacked on !260360. Until that one merges, the diff also shows the commits of the MRs below it. Review only the last 1 commit(s) on this branch.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.

🤖 Generated with Claude Code