Internalize build_params_with and auth behind Grape::Util::InheritableSetting accessors

[ericproulx]

Fourth and final per-key batch of the namespace_inheritable cleanup (after #2805/#2806/#2807): the params-builder strategy written by build_with and the authentication configuration written by the auth DSL are now recorded and read through intention-revealing accessors on Grape::Util::InheritableSetting.

New accessors on InheritableSetting

Accessor	Replaces
build_params_with / build_params_with=	namespace_inheritable[:build_params_with]
auth / auth=	namespace_inheritable[:auth]

Notes:

• build_params_with has two DSL writers — the API-level DSL::Routing#build_with and the params-block DSL::Parameters#build_with — both now funnel through the one accessor, which documents that fact.
• Converted call sites: those two writers, Middleware::Auth::DSL#auth (get-or-set plus the immediate read feeding use Grape::Middleware::Auth::Base), and Endpoint (compile!'s @build_params_with snapshot and warn_unauthenticated_mounted_app's auth presence check).
• With this PR plus Internalize format and error-response defaults behind Grape::Util::InheritableSetting accessors #2805–Internalize routing scope flags behind Grape::Util::InheritableSetting accessors #2807, no code outside InheritableSetting indexes into namespace_inheritable per key anymore — the remaining raw uses are the two bulk to_hash consumers (Endpoint#prepare_default_path_settings, Instance#to_route_configs), which get dedicated accessors in the upcoming visibility-narrowing PR.
• Storage under the raw keys is unchanged; they should now be considered internal.

🤖 Generated with Claude Code

[github-actions]

Danger Report

No issues found.

View run