🐛 fix(bones): skip loadKernel() for rename command on bootstrap

[dansleboby]

Summary

• Guards loadKernel() in BonesCommandLine::boot() so it's skipped when the invocation is rename. rename is the
  bootstrap command that brings vendor and plugin namespaces back into sync; loading the kernel beforehand fatals
  because the plugin's Console\Kernel references the renamed vendor namespace while the freshly reinstalled vendor
  still ships with the default WPKirk\WPBones\... prefix.
• Aligns the implementation with the docblock already on boot(): "a special bootstrap in order to avoid the
  WordPress and kernel environment when we have to rename the plugin and vendor structure."
• Adds vendor/ and .idea/ to .gitignore.

Problem reproduced

On a plugin whose namespace was previously renamed (e.g. WPKirk → Potato), composer update hits the
post-autoload-dump hook and fails before the rename can execute:

```
Fatal error: Uncaught Error: Class "Potato\WPBones\Foundation\Console\Kernel" not found
in plugin/Console/Kernel.php:7
Script php bones rename --update handling the post-autoload-dump event returned with error code 255
```

Root cause

1. composer update reinstalls wpbones/wpbones fresh → vendor namespace resets to WPKirk\WPBones\....
2. post-autoload-dump copies the new bones script into the plugin root and runs php bones rename --update.
3. BonesCommandLine::__construct → boot() unconditionally calls loadKernel().
4. loadKernel() includes the vendor Foundation/Console/Kernel.php (namespace WPKirk\WPBones\...) and then the
   plugin's plugin/Console/Kernel.php, which has use Potato\WPBones\Foundation\Console\Kernel persisted from the
   prior rename.
5. The use alias cannot resolve → fatal at plugin/Console/Kernel.php:7.
6. The rename command — the exact command whose job is to resync these namespaces — never runs.

Chicken-and-egg: loadKernel() assumes vendor and plugin namespaces already agree, but rename --update is precisely
the command that makes them agree.

Fix

```php
if (!in_array('rename', $arguments, true)) {
$this->loadKernel();
}
```

• Detection runs on the $arguments array already computed at the top of boot(). Matches rename, rename --update, and rename "My Plugin" MyNs. rename is not used as a flag anywhere else, so no false positives.
• $this->kernel stays null on the rename path. Both downstream consumers (help display, default command
  dispatch) are already null-guarded.
• Blast radius: only the rename command path changes behavior. Every other command still loads the kernel.

Test plan

• In a renamed plugin (namespace Potato), delete vendor/wpbones/wpbones and the plugin's root bones file,
  then run composer update — post-autoload-dump completes without fatal; bones rename --update rewrites vendor
  namespace to match the plugin and exits 0.
• Confirm vendor/wpbones/wpbones/src/Foundation/Console/Kernel.php now declares namespace Potato\WPBones\Foundation\Console;.
• On a pristine (non-renamed) plugin, php bones --help still lists custom commands — sanity check that the
  non-rename path still loads the kernel.
• php -l src/Console/bin/bones → no syntax errors.