refactor(tasks): ArtifactTask reads its configuration from the task args

[pirhoo]

Closes #2298.

ARTIFACT was the only pipeline stage reading process-wide properties instead of its task args. Moving it to task args exposed four bugs in how a -s settings file resolves against CLI option defaults, on both the legacy jopt parser and the picocli one, so those are fixed here too.

• refactor: ArtifactTask reads its configuration from the task args instead of the injected process-wide PropertiesProvider, like every other stage already does
• fix: substitute a settings-file value before skipping an option that declares no default, so a settings-only artifactDir reaches the ARTIFACT stage instead of failing it
• fix: consult the settings file only when the operator passed -s, so a classpath datashare.properties no longer outranks every option default
• fix: exclude arity-0 booleans from the picocli default value provider, so a settings file setting resume=true no longer makes -r mean "do not resume"
• fix: read the settings file alone via the new PropertiesProvider.getFileProperties(), so DS_DOCKER_* env vars keep the precedence CommonMode gives them instead of beating an option default only when -s happens to be passed
• test: cover the precedence bugs in DatashareCliTest, SettingsDefaultsTest and PropertiesProviderTest

Not covered

• -s<path> (attached short form) is still not parsed by settingsPathFrom, so the settings file is ignored on the picocli path for that invocation style.
• ArtifactTask reads task args through java.util.Properties, so a non-String arg from the API or Temporal is silently dropped.
• DS_DOCKER_* env vars still lose to any option that declares a default, because CommonMode layers the CLI properties on top. That contradicts the precedence documented on SettingsResource.patchSettings, but it predates this branch and changing it would affect every Docker deployment, so it is left alone here.