Release 2.0.1: Interactive wizard and PyPI link fix

[AndrewSillifant]

Summary

• Interactive wizard (hammerdb-scale init -i / --interactive): 6-step guided configuration flow with Rich UI — numbered selection menus, input validation, optional advanced options, and a confirmation summary table before writing
• PyPI documentation links fixed: Converted all relative links in README.md to absolute GitHub URLs so they resolve correctly on pypi.org
• Version bump to 2.0.1

Changes

New files

• src/hammerdb_scale/wizard.py — wizard flow, summary table, step headers
• tests/test_wizard.py — 13 tests covering wizard logic, cancellation, YAML output parity

Modified files

• src/hammerdb_scale/cli.py — added -i/--interactive flag, extracted _build_config_yaml()
• README.md — relative links → absolute GitHub URLs
• docs/USAGE-GUIDE.md — wizard mode documentation
• CHANGELOG.md — 2.0.1 release notes
• Version files: pyproject.toml, __init__.py, constants.py, output.py, reports/generator.py

Test plan

• 137 tests passing (including 13 new wizard tests)
• ruff check and ruff format clean
• Manual walkthrough of hammerdb-scale init -i for both Oracle and MSSQL paths
• Verify generated YAML passes hammerdb-scale validate
• Confirm README links render correctly on PyPI after publish

In general, to fix this issue we must avoid writing the actual password value into the generated YAML file. Instead, we should output either a placeholder string instructing the user how to provide the password securely (e.g., via environment variables or an external secret store) or a reference to an env var, while keeping the rest of the configuration generation unchanged.

The minimal, non‑breaking approach here is:

• Change _build_config_yaml so that the password argument is not interpolated into the YAML.
• Instead, write a safe placeholder such as "${HAMMERDB_DB_PASSWORD}" (or "changeme"), and add commented guidance in the generated YAML snippet to tell the user to define that environment variable (or edit the file manually).
• Keep accepting the password parameter and prompting for it in init, but do not use it in the template content; this avoids larger refactors and still removes the clear‑text storage. If desired later, the unused parameter can be removed, but that’s outside the requested minimal fix.

Concretely:

1. In _build_config_yaml, locate the section:

   250:   defaults:
   251:     type: {db_type_str}
   252:     username: {username}
   253:     password: "{password}"

2. Replace the password line with something like:

   252:     username: {username}
   253:     password: "${HAMMERDB_DB_PASSWORD}"  # set via environment variable; do not commit real passwords

   This breaks the direct dataflow from the user‑supplied password string into the file, addressing all the listed variants at the same sink (line 409).

3. No new imports or external libraries are required; we are just changing the literal generated into the YAML.

All CodeQL variants that refer to config_yaml being written to disk are satisfied because the sensitive input is no longer embedded in config_yaml at all.