Prepare Python SDK for CLI 1.0 workspace settings

[eunomie]

Follow-up to #2 (CLI 1.0 init contract). Makes the Python SDK participate in
CLI 1.0 workspace-scoped SDK settings (dagger settings python-sdk …).

Targets prepare-cli-1.0-init-contract (#2) so the diff is just this change;
rebase onto main once #2 lands.

What this does

Settings have no dedicated SDK capability function — the engine derives the
typed, discoverable settings of an SDK module from its main object's
constructor arguments (constructorHintsFromModule). PythonSdk previously
declared no constructor, so dagger settings python-sdk surfaced nothing.

This PR:

• Adds a PythonSdk constructor declaring the workspace knobs
  defaultPythonVersion / defaultUseUv / defaultBaseImage. They become the
  settings dagger settings python-sdk lists (camelCase → kebab on the CLI:
  default-python-version, default-use-uv, default-base-image) and are
  stored under [modules.python-sdk.settings].
• Has initModule fall back to those defaults when the matching per-init flag
  is omitted; an explicit flag still wins. useUv becomes nullable
  (Boolean = null) so an omitted flag is distinguishable from an explicit
  --use-uv=false — mirroring the nullable-boolean pattern already in
  mod-config.dang. The only new logic is the defaulting; configuredTemplate
  still consumes the resolved values.
• Adds an e2e check (initSettingsDefaultCheck) covering both inheritance of
  the constructor defaults and per-init override, and documents the settings in
  the README.

skipGenerateFilename / targetRuntime keep their inline defaults and are
intentionally not constructor args, so they don't leak in as settings.

dagger settings python-sdk default-python-version 3.13
dagger settings python-sdk default-use-uv false
dagger settings python-sdk default-base-image python:3.13-slim

Scope / what lands now

• ✅ dagger settings python-sdk default-* is discoverable, typed and stored.
• ✅ On the dagger call python-sdk … path the engine populates the constructor
  from the stored settings, so initModule honors them there.
• ⏳ The privileged dagger module init python dispatch does not yet thread
  [modules.python-sdk.settings] into the SDK constructor, so "new modules
  inherit the workspace default" through the real init command needs an
  engine-side follow-up (thread settings into
  core/sdk/module.go:instantiate / core/schema/workspace_module_init.go on
  design/cli-1.0). This SDK change is correct and harmless ahead of it. The
  e2e harness instantiates pythonSdk directly, so it can already cover the
  constructor-default path.

Out of scope (needs a design decision, not guessing)

dagger module sdk per-module alignment: the wrapper dispatches
dagger call <sdk> <subcommand> without injecting the current module's path,
which doesn't match this SDK's path-based mod config surface. The contract is
underspecified — left for the design/cli-1.0 owner to resolve before aligning
the per-module surface.

Notes

• No engine in the dev sandbox, so the Dang changes can't run locally — CI's
  @check suite is the validator.
• python-sdk pins engine v0.21.3 → Dang v1 semantics.