feat: Auto-discover assembly ID and validate plugin class in step scaffolding

[TomProkop]

Context

The pp-plugin-assembly-step template previously required an AssemblyId GUID that users had to manually look up from the scaffolded assembly XML. PR #31 (templates v1.17.0) removed this parameter and uses recursive file lookup instead — a good improvement.

However, the user still needs to have built the solution first so the PluginAssemblies/*.dll.data.xml exists. If they haven't, the post-action scripts fail with less-than-obvious errors.

Proposal

Make step scaffolding smarter with pre-flight checks:

1. Auto-discover assembly metadata

Before running post-actions, check for PluginAssemblies/*.dll.data.xml:

• Found → extract PluginAssemblyId, PublicKeyToken, and <PluginTypes> list automatically
• Not found → clear error: "Assembly XML not found in PluginAssemblies/. Build the solution first: dotnet build src/Solutions.Logic"

2. Validate plugin class name

Check that the specified --PluginName exists in the assembly's <PluginTypes> list:

• Found → proceed, extract PluginTypeId
• Not found → error with available classes: "Plugin class 'MyPlugin' not found. Available types: SubtractQuantityPlugin, ValidateWarehouseTransactionPlugin"

3. Suggest build command

If assembly XML is stale (modification time older than plugin .cs files), warn: "Assembly XML may be outdated. Consider rebuilding: dotnet build src/Solutions.Logic"

Implementation notes

• Pre-flight checks belong in the post-action scripts (.ps1 / .csx) or in a new pre-action hook
• PR feat: MCP progressive disclosure — guide tools, sampling, skills knowledge base #31 already added null checks on $pluginType XPath result — this extends that with a better error message listing available types
• The SetPluginTypeId.ps1 script already does the XPath lookup; add enumeration of available types on failure

Priority: �� Low | Effort: Small