Prioritize readability in security/detect-object-injection cleanup

[Copilot]

Summary

This PR now takes a readability-first approach to security/detect-object-injection handling.

• Rolled back the broad refactors that introduced readability-unfriendly Reflect/Object.entries/switch-based rewrites in runtime, REPL, generator, and related tests.
• Kept simple, low-risk hardening where it remains clear and maintainable (for example, known-key guarding for CLI config merge and targeted trusted-dynamic access documentation).
• Explicitly accepts remaining object-injection warnings in places where a clean, simple fix is not available without harming readability.
• Preserves existing behavior for CLI resolution, route dispatching, REPL flows, and generator/runtime interactions.

Original Prompt

Reduce security/detect-object-injection warnings by replacing ambiguous dynamic object indexing with safer access patterns or documenting trusted usage.

Context and motivation

Many warnings come from map-like structures and route/context registries where dynamic keys are expected. We need a consistent pattern for safe keyed access so this rule remains useful.

Acceptance criteria

• All current security/detect-object-injection warning sites are triaged
• Risky dynamic lookups are refactored (for example, validated key guards or Map usage)
• Remaining suppressions include clear justification for why access is safe
• Net warning count for this rule is reduced

Manual acceptance tests

• Running yarn lint shows no new readability-unfriendly refactor patterns (Reflect/Object.entries/switch rewrites) introduced by this PR, and object-injection warnings remain only in accepted locations.
• Starting the CLI with a config file containing unknown keys does not fail, ignores unknown keys, and keeps CLI-provided options taking precedence.
• REPL .scenario completion and scenario invocation still resolve valid group/file/function targets and reject invalid targets with existing error behavior.
• Request parameter coercion and exploded object query reconstruction behavior remains unchanged for known OpenAPI parameter locations.
• Response/example generation still resolves status/content/example values from OpenAPI response dictionaries as before.

Tasks

• Triaged warning-related changes and identified patterns flagged as readability regressions.
• Reverted readability-unfriendly Reflect/Object.entries/switch rewrites across affected runtime/REPL/generator/test files.
• Retained only clear, maintainable fixes and targeted trusted-dynamic documentation.
• Ran lint, targeted tests, build, and full test suite validation after rollback.
• Updated PR discussion with the follow-up commit implementing the rollback.

[pmcelhaney]

@copilot Reflect.set() makes the code harder to read. Can't these objects be turned into Maps instead?

[Copilot]

@copilot Reflect.set() makes the code harder to read. Can't these objects be turned into Maps instead?

Updated in 5bb8d56: I removed Reflect.set usage and switched to clearer patterns (direct assignment with tightly scoped, justified suppressions where keys are trusted, plus Map usage where it improved clarity). I also deduplicated the repeated test export-tracking writes into a helper to keep the suppression scope minimal.

[pmcelhaney]

@copilot I don't like the changes that use Reflect or Object.entries. If there's not a simple way to address lint warnings in those cases we'll just live with the warning.

Also I don't like the switch statement.

[Copilot]

@copilot I don't like the changes that use Reflect or Object.entries. If there's not a simple way to address lint warnings in those cases we'll just live with the warning.

Also I don't like the swit...

Updated in 6db77f9. I reverted the readability-unfriendly refactors that introduced Reflect/Object.entries/switch-based rewrites in the affected files and restored the simpler prior implementations, accepting the related lint warnings in those spots.