fix: regenerate vector config on app lifecycle changes

The generated vector config is a snapshot of the app list and their sink properties, but it was only ever written by `logs:set` and `logs:vector-start`. Renaming an app left a source filtering on a label no container carries and gave the new name no source at all, so the app kept a sink with nothing feeding it. Cloning produced the same result for the clone, and destroying an app left its source and sink behind, the latter still pointing at an endpoint decommissioned along with the app. The global relabel transform embeds app names directly in generated VRL, so a rename also left behind a branch naming an app that no longer existed. Every case was silent, and the only repair was an operator running `logs:vector-start`. The `post-app-clone-setup`, `post-app-rename-setup` and `post-delete` triggers now rewrite the config, warning rather than failing so that a config write cannot abort the app operation whose state it is derived from.

Closes #8918.

plugins/logs/functions.go

@@ -538,6 +538,17 @@ func vectorScopes() []vectorAppSinks {
 	})
 }
 
+// regenerateVectorConfig rewrites the generated vector config so that it matches
+// the current set of apps and their properties. App lifecycle triggers call this
+// instead of writeVectorConfig because the config is derived state: failing to
+// rewrite it should not abort the app operation that changed the state it is
+// derived from.
+func regenerateVectorConfig() {
+	if err := writeVectorConfig(); err != nil {
+		common.LogWarn(fmt.Sprintf("Unable to write updated vector config: %s", err.Error()))
+	}
+}
+
 func writeVectorConfig() error {
 	data, err := buildVectorConfig(vectorScopes())
 	if err != nil {