Scaffold a Python CLI tool whose flags, config file, and environment variables don't silently fight each other

Build a Python CLI tool using Click. This needs to work as a real command-line tool other people or scripts will invoke, not a demo script — that means config precedence, exit codes, and error messages all have to be deliberate, not accidental.

WHAT THE TOOL DOES
Syncs a local directory of markdown files to a remote S3 bucket, skipping files that haven't changed since the last sync.

SUBCOMMANDS NEEDED
sync (does the actual upload), status (shows what would change without uploading), init (writes a starter config file)

CONFIG SOURCES
bucket name and AWS profile can come from a .syncrc file or env vars; --dry-run and --verbose are flag-only.

WHO/WHAT WILL INVOKE THIS
Runs both interactively by engineers and inside a nightly CI job that needs to fail the pipeline on a real error but not on 'nothing to sync'.

RULES
Define one explicit precedence order for settings that can come from more than one of: a config file, environment variables, and CLI flags — state the order plainly (e.g. CLI flag overrides env var overrides config file overrides built-in default) and implement it that way consistently across every setting, rather than letting each option's implementation drift independently, which is how tools end up with one flag that overrides the config file and another that silently doesn't. Every subcommand needs a docstring Click will surface in `--help` that states what it does and, for anything destructive, what it will NOT undo. Distinguish exit codes deliberately: 0 for success, a distinct non-zero code for "ran correctly but found nothing to do / a validation failure the user caused" versus a different code for "an unexpected internal error" — because the invocation context above determines whether a calling script needs to branch on that distinction, and collapsing everything to exit code 1 makes that impossible. Validate all user input at the CLI boundary with clear error messages that name which argument was wrong and why, before any side-effecting logic runs — never let a malformed flag surface as a stack trace.

WHAT NOT TO DO
Do not use `print()` for anything other than the tool's actual output going to stdout; route diagnostic/progress messages to stderr via Click's `echo(..., err=True)` so stdout stays pipeable. Do not silently swallow an exception to "keep the CLI clean" — a caught exception must either be handled with a specific recovery action or re-raised with added context, never passed and ignored.

OUTPUT FORMAT
1. The full Click CLI code (entry point, subcommands, config loading in precedence order).
2. A short table: exit code -> meaning -> when it happens.
3. One example `--help` output for the main command.
4. A one-paragraph note on how a calling script should check success/failure of this tool.