`--working-directory` has no effect since 0.65.0

New Issue Checklist

• I've Updated SwiftLint to the latest version.
• I've searched for existing GitHub issues.

Bug Description

--working-directory no longer takes effect. The configuration file is still looked up in the directory SwiftLint was started from, so it is not found and SwiftLint silently falls back to the default configuration.

mkdir -p ~/a/b
printf 'disabled_rules:\n  - identifier_name\n' > ~/a/.swiftlint.yml
printf 'enum Size {\n    case m\n}\n' > ~/a/b/Bad.swift

cd ~/a/b
swiftlint lint --working-directory ~/a --no-cache --quiet ~/a/b/Bad.swift

~/a/.swiftlint.yml disables identifier_name, so 0.64.1 and earlier report nothing. 0.65.0, 0.65.1 and main report:

~/a/b/Bad.swift:2:10: error: Identifier Name Violation: Enum element name 'm' should be between 3 and 40 characters long (identifier_name)

The defer restoring the directory in LintOrAnalyzeCommand.run(_:) is scoped to the if let workingDirectory block, so it fires at that block's closing brace, before linting starts. It was added in #6048. Moving it to the function's scope, with the restore target held in an optional so that the directory is only restored when the option actually moved it, would fix it without changing anything when the option is not passed. I'm happy to open a PR.

This mainly hurts the SwiftPM plugins, which run from the package directory and need the option to reach a .swiftlint.yml above it.

Environment

• SwiftLint version 0.65.1 (0.65.0 and main are also affected, 0.64.1 and earlier are not)
• Xcode 26.5
• Installation method used: official SwiftLintBinary.artifactbundle release
• Configuration file:

disabled_rules:
  - identifier_name

No nested configurations.

Start at LintOrAnalyzeCommand.run(_:) and reproduce the issue with the provided SwiftLint command and configuration. Inspect when the working directory is restored relative to linting, then verify that --working-directory finds ~/a/.swiftlint.yml and suppresses the identifier_name violation without changing behavior when the option is absent.