Bulk apply reports `updated` for a document that changed nothing, so a client cannot tell a no-op from a write

[lex00]

Measured today against a v0.16.0 instance while checking that a chant-authored manifest applies idempotently.

Applying the same manifest twice, unchanged, the second apply reports:

Environment/toolchain   updated
Vault/prod-creds        updated
Agent/prod-steward      updated

ApplyResult.action is created | updated | error, so a document that reconciled to exactly what was already stored is indistinguishable from one that wrote a real change. A client that wants to report "nothing drifted" has to diff the estate itself, or read every resource back and compare.

The ask is one more value, unchanged, returned when reconciliation produced no field change. Everything else about the endpoint already behaves idempotently, which is what makes the reporting gap visible.

Context for why a client cares: chant renders an apply summary a person reads before deciding whether an environment drifted, and its own reconciler for the three team-side kinds (INTENTIUS/chant#2127) already reports unchanged because it compares before writing. The three kinds that go through bulk apply cannot, so one summary carries two different meanings for the same word.

Related: #1636, which extends bulk apply to Teammate, Schedule and Webhook. If those land here, they will want the same third value.

[lex00]

This is implemented in #1675, which is open now.

ApplyResult.action gains unchanged, returned when reconciliation produced no field change. It is computed by comparing the record before and after the context call over the schema's own fields, timestamps excluded, so it reports on what was actually written rather than on whether an update was attempted.

Two details worth knowing before a client reads it:

• It covers all six kinds, because that PR also extends apply to Teammate, Schedule and Webhook (Bulk apply: accept Teammate, Schedule and Webhook documents so one manifest reconciles the whole estate #1636). A manifest holding all six applied twice reports every row unchanged on the second pass, which is the test that pins it.
• Inline spec.secrets are re-encrypted on every apply, so a row can report unchanged while its secrets entries report upserted. The row's verdict is about the resource's own fields. This is called out in the moduledoc, the operation description, docs/api.md, docs/cli.md and the help topic.

The same PR also stops an unchanged re-apply writing an *.updated audit event for environments, vaults, agents and webhooks. That was the other half of "nothing drifted": the result row said updated and so did the trail.