feat(azure): Microsoft.Web (App Service) — 7 resource types

[naxty]

Closes the Microsoft.Web (App Service) gap: the plugin had zero PaaS compute
coverage, which the coverage gap analysis flagged as its single
biggest hole. Seven new resource types, all on
armappservice/v5 (already a dependency), all at api-version 2025-03-01.

Base is naxty/wave1-plumbing (PR #125) — this branch depends on the App Service
clients that commit adds to pkg/client/client.go.

Resource types

formae type	ARM type	client	write path
AZURE::Web::ServicePlan	Microsoft.Web/serverfarms	PlansClient	LRO create/update, sync delete
AZURE::Web::WebApp	Microsoft.Web/sites	WebAppsClient	LRO create/update, sync delete
AZURE::Web::FunctionApp	Microsoft.Web/sites (kind=functionapp*)	WebAppsClient	LRO create/update, sync delete
AZURE::Web::WebAppSlot	Microsoft.Web/sites/{site}/slots/{slot}	WebAppsClient slot methods	LRO create/update, sync delete
AZURE::Web::Certificate	Microsoft.Web/certificates	CertificatesClient	fully synchronous
AZURE::Web::CustomHostnameBinding	Microsoft.Web/sites/{site}/hostNameBindings/{host}	WebAppsClient binding methods	fully synchronous
AZURE::Web::StaticSite	Microsoft.Web/staticSites	StaticSitesClient	LRO create/update and LRO delete

New schema modules live in schema/pkl/web/; Go provisioners in
pkg/resources/. No shared file is touched — resources self-register via
init().

The non-obvious decisions

The site GET returns an empty siteConfig. ARM says so explicitly ("this
property is not returned in response to normal create and read requests since it
may contain sensitive information"), so WebApp, FunctionApp and WebAppSlot
all make a second call to .../config/web on the read path and merge the
result in. A missing config resource is tolerated and the block is omitted.

appSettings is a top-level write-only field, not nested in siteConfig.
Two reasons: annotations are only honoured on top-level fields, and Azure serves
app settings from a separate endpoint that also returns platform-injected
settings no forma declared — reading them back would be permanent drift. They are
sent on every create and update and never read back, so drift in them cannot be
detected. Same trade-off containerapp's secret values already make.

Discovery is partitioned by kind. WebApp and FunctionApp are the same
ARM type, so WebApp.List drops sites whose kind carries functionapp and
FunctionApp.List keeps only those. Without the split every site would be
reported twice, once per formae type. Both sides are tested over one mixed
listing.

A non-functionapp kind on a FunctionApp is an error, not a correction.
Silently fixing it would create a plain web app under a resource claiming to be a
function app — and the next discovery pass would not even see it as this type.

Nested hasProviderDefault is annotated but documented as not working. Azure
fills in sku.tier, sku.capacity and every siteConfig field whether or not
the create body set them, and the conformance framework only honours the hint on
top-level fields. Every nested field is annotated, and each schema and fixture
carries a comment saying to set them explicitly. This is the same caveat
eventhubnamespace's NamespaceSKU already documents.

Secret-bearing fields (pfxBlob, password, repositoryToken, and any
appSettings value) are writeOnly = true and typed (formae.Value|String) so
they can be wrapped with formae.value(...).opaque. pfxBlob carries base-64
text while the SDK model is raw bytes it re-encodes on the wire, so the plugin
decodes on the way in and rejects invalid base-64.

Other house-pattern details: armIDParts for every ID parse,
canonicalizeEnum on every enum read (ARM hands sslState back lower-cased,
sku.name as free), normalizeAzureLocation on location ("East US 2" →
eastus2), isDeleteSuccessError so a 404 delete is success, and an in-flight
LRO create that pins the ARM ID the resource will land at.

Fixtures

testdata/{app-service-plan,web-app,function-app,web-app-slot,app-service-certificate,custom-hostname-binding,static-site}{,-update}.pkl
— 14 files. Each -update changes only non-createOnly fields.

Cost/shape notes baked into the fixture headers: Linux B1 plans throughout
except web-app-slot, which needs S1 (slots need Standard or better and ARM
rejects the create otherwise); static-site uses the Free SKU in eastus2
(Static Web Apps ships in few regions) and is created detached — no
repositoryUrl, so no GitHub PAT and nothing billed. function-app wires storage
with the identity-based connection form
(AzureWebJobsStorage__accountName + __credential = managedidentity) rather
than a connection string, because formae cannot resolve storage account keys —
and it runs on a dedicated plan rather than Consumption, which validates the
storage connection at create time.

Two fixtures cannot pass conformance — please exclude them from the matrix

Neither for a plugin reason. Both are the same class of exclusion
cdn-afd-custom-domain and cdn-secret already carry in
.github/conformance-matrix.txt, and both fixtures say so in a header comment:

• custom-hostname-binding — Azure verifies domain ownership before it
  accepts a binding: the hostname must already resolve to the app through a CNAME
  (or an A record plus an asuid.<host> TXT record) in the domain's real DNS
  zone. The conformance subscription owns no domain, so every create fails with
  CustomDomainVerificationFailed. There is no hostname it could succeed with.
  The fixture uses www.example.com (IANA-reserved for documentation) so the
  placeholder cannot accidentally bind a real domain.
• app-service-certificate — Azure validates the certificate against the
  hostnames of apps on the referenced App Service plan and rejects anything whose
  subject matches no verified custom domain in it. With no domain there is no
  certificate it would accept. pfxBlob is a syntactically valid but meaningless
  base-64 string so the fixture still evaluates and still exercises the
  marshalling path.

Run either live locally against a real domain/certificate with
make conformance-test-crud TEST=custom-hostname-binding /
make conformance-test-crud TEST=app-service-certificate.

The other five (app-service-plan, web-app, function-app, web-app-slot,
static-site) are written to pass and should go in the matrix. One caveat worth
stating plainly: the siteConfig round-trip has not been exercised against
live ARM. Every field Azure fills in is spelled out in the fixtures
(netFrameworkVersion = "v4.0" even on Linux, functionAppScaleLimit = 0 on a
dedicated plan) based on what ARM documents and az webapp config show returns,
but one live run may still turn up a field that needs adding or dropping from the
fixture. healthCheckPath is deliberately left out of the fixtures: Azure returns
it empty when unset and the plugin skips empty values, so an omitted path is
drift-free.

Verified

$ gofmt -l pkg schema
(no output)

$ go build ./...
Success

$ go vet ./...
No issues found

$ go test ./pkg/...
1060 passed in 6 packages

$ go test -tags=integration ./pkg/...
1813 passed in 6 packages

$ go test -tags=unit ./pkg/...
1117 passed in 6 packages

$ make lint
0 issues.

$ make verify-schema
Status: PASSED — 156 modules, 155 resource types, 0 duplicate files, 0 duplicate types

$ make lint-reuse
Files with copyright information: 860 / 860 — compliant

All 14 new fixtures were additionally evaluated with pkl eval against the local
schema project (in a scratch project so no PklProject was added to testdata/)
to confirm they render.

No conformance test was run and nothing in this branch touched real Azure, per
the wave brief.

Deliberately left out

• AZURE::Web::Certificate's expirationDate / issueDate — read-only time
  fields whose formatting is a drift risk with no upside.
• Slot swap (SwapSlot) — an imperative operation, not declarative state.
• Static Web App custom domains, database connections and linked backends — their
  own ARM child types, out of scope for this batch.
• AZURE::Web::WebAppSlot does not model identity, publicNetworkAccess or
  virtualNetworkSubnetId; the read path explicitly does not emit them, so state
  can never hold a property no forma can express.
• Nothing was dropped for difficulty: all seven types in the brief are here.

Follow-up for the orchestrator

• README resource-table rows for the seven types.
• .github/conformance-matrix.txt: add app-service-plan, web-app,
  function-app, web-app-slot, static-site; leave
  custom-hostname-binding and app-service-certificate out with the reasons
  above.
• CHANGELOG entry.