[Feature]: Add a `packageguard init` command that scaffolds a configuration from actual dependencies

### Background and motivation

Adopting PackageGuard starts with an empty configuration file and a question the user cannot answer yet: which licenses should I allow? The only way to find out is to write a guess, run the tool, read the failures, and iterate. That is a poor first experience, and it is the moment where most evaluations are abandoned.

The tool already has everything needed to answer the question, because after one scan it knows exactly which licenses and packages are actually present.

**Proposal**

```bash
packageguard init
```

An interactive command that scans the repository, summarises what it found, and writes a configuration reflecting the current reality:

```
Scanning C:\src\MyProduct...
Found 247 packages across 12 projects.

Licenses in use:
MIT 184 packages
Apache-2.0 41 packages
BSD-3-Clause 9 packages
MS-PL 7 packages
LGPL-2.1-only 4 packages <- weak copyleft
GPL-3.0-only 2 packages <- strong copyleft
(unknown) 1 package <- SomeObscurePackage 1.2.0

What kind of software is this?
> Proprietary / commercial (suggests: permissive only)
SaaS / hosted (suggests: no network copyleft)
Open source (suggests: OSS friendly)

Written .packageguard/config.json
2 packages violate the suggested policy. Run `packageguard .` to see them.
```

Design points:

- **Show reality before asking for a decision.** Listing what is actually in the repository, with counts and copyleft flagged, is the part that makes the choice informed rather than arbitrary.
- **Do not silently allow everything present.** Generating a config that permits exactly what is already there produces a policy that can never fail and gives false confidence. Suggesting a sensible policy and then reporting what does not fit is the honest outcome.
- **Non-interactive mode.** `packageguard init --preset permissive-only --yes` for scripted setup and for use in templates.
- **Never overwrite silently.** If a configuration already exists, refuse unless `--force` is given.
- **Explain the copyleft distinction.** A one-line explanation of what LGPL or GPL means for the user's situation is more valuable at this moment than anywhere else in the documentation.
- **Comments in the generated file.** The config format already tolerates comments (the README example uses them), so the generated file can explain each section inline.

This pairs naturally with policy presets: `init` picks the closest preset and the generated file simply extends it, keeping it short and upgradable.

### Alternative Concerns

- The README already contains a copyable example, which is cheap and helps, but it does not reflect the user's actual dependencies.
- A `--suggest-config` flag on the normal analyze command would achieve something similar without a new command, though it fits the mental model less well.

### Are you willing help with a pull-request?

No

Start by tracing the existing packageguard scan command and configuration handling, since the issue does not name specific files or tests. Map how dependency and license results are collected, then determine where the init entry point, preset selection, interactive prompts, non-interactive flags, and safe file creation belong; done means the proposed command reports findings and produces the documented configuration behavior.

Written by the indexing model from the issue text.