Fix discovery guidance for whole-project scaffold templates

[TomProkop]

Summary

Six plugins/implement/skills/*/SKILL.md files tell the agent to discover a
"component type" with txc component type list --search <term> before
txc workspace component create <type>. That works for genuine Dataverse
solution-component types (Entity, Form, SavedQuery, PluginAssembly, …),
but it structurally cannot find whole-project scaffolds (pp-package,
pp-plugin, pp-pcf, pp-script-library, pp-app-code, pp-page-generative,
pp-plugin-test, pp-test-script, pp-test-ui, pp-test-ui-feature,
pp-form-event-handler) — those are dotnet new template short names from a
different namespace of the same TALXIS.DevKit.Templates.Dataverse package,
invisible to any txc command. txc workspace component create <type> accepts
both namespaces identically; only discovery was missing for one of them.

Verified against a real txc 1.19.0 install — every search below returns [],
while dotnet new list | grep -i "power platform" finds all of them and
txc workspace component create <shortname> --output <path> works end to end:

txc component type list --search package   -> []
txc component type list --search test      -> []
txc component type list --search page      -> []
txc component type list --search code      -> []
txc component type list --search script    -> []
txc component type list --search handler   -> []
txc component type list --search "event handler" -> []
txc component type list --search feature   -> []
txc component type list --search plugin    -> [PluginAssembly, SdkMessageProcessingStep]  (registration types only, not the pp-plugin project template)

This wasted real agent time: following init's literal instruction for
--search package returns nothing, and without knowing the project-template
namespace exists at all, the agent has to reverse-engineer the whole
dotnet new/TemplateEngine architecture from scratch to find dotnet new list.

Changes

• TOOLING-BACKLOG.md — adds T17 for the underlying txc gap (no
  discovery command sees its own template package's project-level templates).
• init/SKILL.md — step 4's package-project discovery now points at
  dotnet new list; adds init/references/project-scaffolds.md (the skill
  had no references/ directory at all) explaining the two-namespace split.
• backend/SKILL.md + references/plugin-development.md — the "C# project"
  row/CLI line no longer claims --search plugin finds the project template
  (it only returns the registration types); folds the correct discovery
  command into the existing reference file's Step 2.
• frontend/SKILL.md + references/{code-apps,generative-pages,form-scripts}.md
  — fixes the generative-page, code-app, and script-library/form-event-handler
  rows the same way. (The "event handler types" half of the old script row was
  also re-verified as flat wrong — --search handler/--search "event handler"
  return [] too, not a partial match as I'd first guessed.)
• test/SKILL.md + references/{unit,ui}.md — the whole intent table was
  wrong (plugin test, script test, UI test + feature all live only in
  dotnet new list); fixed all three rows and folded the discovery note into
  the two existing reference files.
• data-model and security skills are untouched — their search terms
  (Entity/Table, relationship, optionset, role, privilege) resolve
  correctly against the real component-type registry.

Test plan

• node scripts/generate-manifests.mjs && node scripts/validate.mjs — passes,
  no manifest drift.
• Re-verified every --search claim above against a live txc 1.19.0
  install and cross-checked with dotnet new list.
• Confirmed txc workspace component create pp-package --output <path> and
  ... pp-entity --output <path> both succeed end-to-end (the create
  command already handles both namespaces fine — only discovery was
  broken).

🤖 Generated with Claude Code