[6.x] Stop the Yii adapter from logging deprecations for its own calls

[brandonkelly]

Description

The Yii adapter was calling deprecated APIs internally, so the Deprecation Warnings utility listed warnings that no project or plugin code had triggered. This updates the adapter's own code to use the non-deprecated APIs:

• The legacy Fields and Sites services fired their Yii events through Craft::$app->getFields()/getSites(), which log a deprecation on every call. They now fetch the Yii component directly.
• A project's general config built with the legacy craft\config\GeneralConfig was rebuilt through __set_state(), which set every property — including deprecated ones like isSystemLive and generateTransformsBeforePageLoad — and logged their deprecations even when the project never set them. Legacy configs are now copied instead.
• Craft::$app->getConfig()->getGeneral() callers (Local filesystem, FileHelper, Paginate) now use Cms::config().
• Element queries called andWhere()/scalar(), and elements called addError(), setScenario(), getErrors() and getErrorSummary(), which go through the deprecation-logging compatibility mixins. They now use the Laravel query methods (where(), whereIn(), value()) and errors()/ruleset->useScenario(). This covers legacy tags, categories, global sets (incl. their GraphQL resolvers and settings template), the entrify/resave console controllers, the ReplaceRelations job, Model::addModelErrors(), and the craft\test helpers.
• craft:utils:repair:category-group-structure now hands its query to the core RepairCommand::repairStructure(), which already applies the same structure join and draft filtering, rather than rebuilding it in Yii syntax.

Not addressed here: Tag, Category and GlobalSet still run yii validators against the element itself, so a failing legacy rule (and GlobalSet's UniqueValidator, on every validation) still logs addError/hasErrors deprecations.

🤖 Generated with Claude Code