Foundry connections declared as host: azure.ai.connection services are
now created at provision time by the microsoft.foundry provider, so the
deploy-time service target no longer upserts them. This removes the
redundant ARM write on every azd deploy and makes provision the single
source of truth, mirroring the azure.ai.project target (also a no-op
because the project is provisioned by the same provider).

- Deploy returns an empty result with an informational message; the
  target still owns the azure.ai.connection host so azd can walk the
  entry in the deploy graph (uses: ordering for toolboxes/agents)
- drop the now-dead upsert helpers (parse/env/credential/metadata) and
  replace their tests with no-op coverage

Depends on the agents change (provision-time synthesis) landing first so
connections are always created by provisioning.

ARM's management SDK mangles output-name casing (e.g. AZURE_AI_PROJECT_ID
comes back as azurE_AI_PROJECT_ID). armOutputsToProto repairs known names
via a case-insensitive match against canonicalOutputNames, but the new
AZURE_AI_PROJECT_CONNECTION_NAMES output was missing from that list, so it
landed in .env as azurE_AI_PROJECT_CONNECTION_NAMES instead of the
canonical name. Found live while running the e2e test plan for
provision-time connections.

Add the missing entry and a matching case in
TestArmOutputsToProto_RepairsMangledKeyCase.

Both files are dead weight in a greenfield eject: ejectInfra already
refuses to eject a brownfield (endpoint:) project, main.bicep has no
module reference to brownfield.bicep, and the provider's brownfield
deploy/preview path always loads the embedded
synthesis.BrownfieldARMTemplate() rather than anything under infra/ -
even after later adding endpoint: while infra/main.bicep still exists
on disk. Shipping them in every eject only invited confusion about
whether they were required.

writeEmbeddedTemplates now excludes brownfield.bicep and
brownfield.arm.json the same way it already excluded main.arm.json.
Verified live: a fresh --infra eject no longer writes either file.

…ns are pending

deployBrownfield's progress-message switch only covered
deployments+ACR/ACR-only/default, so a brownfield project declaring just a
connection (no deployments, no ACR) printed "reconciling declared model
deployments..." even though zero deployments existed. Found live while
testing brownfield connection creation.

Replace the switch with brownfieldReconcileMessage(hasDeployments, createACR,
hasConnections), which names only what's actually pending. Callers only
reach it when at least one is true (the earlier guard skips provisioning
entirely otherwise), so the message never claims work that isn't happening.

Add TestBrownfieldReconcileMessage covering all 7 reachable combinations,
including the connections-only regression case. Verified live: provisioning
now prints "reconciling connections..." for that case.

No logic changes -- reviewed the full branch diff against origin/main for
unnecessary code and comment verbosity.

- azure.ai.connections/service_target.go: the same fact ("connections are
  created at provision by microsoft.foundry, so Deploy is a no-op") was
  stated three times (const, struct, and method doc comments). Kept the full
  explanation on Deploy only; trimmed the other two to brief pointers.
- synthesizer.go: shortened the Connection type, BrownfieldConnections, and
  collectConnections doc comments to match the concision of sibling
  functions (e.g. BrownfieldDeployments).
- foundry_provisioning_provider.go: trimmed brownfieldReconcileMessage's
  doc comment.
- init_infra.go (+ matching test comment): trimmed the brownfield.bicep
  exclusion rationale, which had grown to a 13-line bullet repeating detail
  already covered by the commit history.

No unnecessary/dead code was found beyond comments -- the connectionType
Bicep duplication across main.bicep/resources.bicep/brownfield.bicep/
connections.bicep matches the pre-existing deploymentType pattern (Bicep has
no cross-file type import), and the Connection/connectionService type split
in synthesizer.go mirrors existing splits like agentBlock/serviceBlock.

Verified: go build, full test suite, gofmt, and golangci-lint all pass
unchanged on both azure.ai.agents and azure.ai.connections.