Turn a one-off Python script into a proper CLI tool

Convert the script described below into a real command-line tool — not a script with sys.argv indexing, and not one that still has hardcoded values a user has to edit before running it.

CURRENT SCRIPT
A script that reads a folder path and a threshold hardcoded at the top, then deletes log files older than the threshold.

FRAMEWORK
Use Typer. If it's Typer, define arguments as type-hinted function parameters — that's Typer's actual mechanism — rather than manually building a parser. If it's Click, use the @click.command() and @click.option/@click.argument decorators. If it's argparse, use argparse.ArgumentParser with explicit type=, required=, and help= on every argument.

COMMANDS NEEDED
single command: clean, with options for folder, days-old threshold, and file extension filter

DESTRUCTIVE BEHAVIOR
Permanently deletes matched log files from disk; no recycle bin or backup.

REQUIREMENTS
1. Every option has a help string a stranger could act on without reading the source — "path to clean" not "the folder."
2. Every option with a sensible default gets one; every option that doesn't must be required and say so, rather than silently defaulting to None and failing three lines later with an unrelated AttributeError.
3. Validate inputs at the CLI boundary (file exists, path is a directory not a file, number is in range) and exit with a clear message and a non-zero exit code — never a raw traceback as the user-facing output.
4. Use meaningful exit codes: 0 for success, and distinct non-zero codes for distinct failure classes if there's more than one, documented in a comment.
5. If Permanently deletes matched log files from disk; no recycle bin or backup. describes anything that deletes, overwrites, or sends data, add a --dry-run flag that reports exactly what would happen, and default the destructive path to off unless --yes or --force is explicitly passed — never make the default invocation the destructive one.
6. Support --help correctly on both the top-level command and every subcommand named in single command: clean, with options for folder, days-old threshold, and file extension filter — a user should be able to discover every option without reading source code or guessing at flag names from a README that may be out of date.
7. If the tool reads or writes any path, resolve it relative to the current working directory the way a shell user expects, and say explicitly whether relative paths are resolved against the invocation directory or some other base — a script silently resolving paths against its own install location instead of where the user actually ran it from is a common and confusing surprise.
8. Print user-facing output to stdout and errors to stderr, not both mixed on stdout — this is what lets the tool be piped and scripted correctly by anything downstream that expects to separate normal output from failures.

OUTPUT FORMAT
1. The CLI entry point code.
2. The exact pyproject.toml [project.scripts] entry needed to install it as a real command.
3. Three example invocations: one happy path, one that fails validation, one using --dry-run if applicable.
4. Confirmation that --help produces useful output for the top-level command and every subcommand, and where stdout versus stderr is used.