feat: func doctor

`func doctor` should run deterministic environment + project checks to
catch the misconfigurations that drive a large share of incoming ICMs.
Spec the command, the check framework, and the initial check set
before any implementation work.

## Definition of Done

- [ ] Goals + non-goals documented
- [ ] Check framework design: how checks are authored, registered,
run, and reported
- [ ] Initial check set scoped (e.g. .NET SDK, workload manifest
health, Azurite, port conflicts, workload package cache)
- [ ] Output UX defined (status, remediation hints, `--verbose`
behavior) via `IInteractionService`
- [ ] Exit code + scripting story defined
- [ ] Extensibility story: can workloads contribute checks?
- [ ] Integration story with [azure-functions-skills](https://github.com/Azure/azure-functions-skills)
decided (the skills repo already ships a doctor command that runs
LLM-driven skills to validate config + code; ~53% of incoming
ICMs could be prevented by keeping these skills current). Does
`func doctor` shell out to the skills runtime, does the skills
doctor call into `func doctor` for deterministic checks, or do
they stay independent?
- [ ] Follow-up implementation issues opened

Start with the Definition of Done and turn each item into the proposal sections for goals, check authorship and registration, initial checks, output, exit codes, extensibility, and follow-up issues. Use IInteractionService for the output UX and compare the integration options with the existing doctor command in azure-functions-skills; done means the design decisions and implementation follow-ups are documented.

Written by the indexing model from the issue text.