Fix rest-openapi, observation, and twitter-salesforce examples

[Croway]

Summary

• rest-openapi: fix the actuator URL in the README — the documented http://localhost:8080/actuator/ (trailing slash) returns a 404; the working URL has no trailing slash. Also refreshed the stale sample startup log, which showed Spring Boot 1.5.10.RELEASE / Camel 2.22.0-SNAPSHOT output from 2017, with output captured from a verified run against the current stack (Spring Boot 4.1.1, Camel 4.23.0-SNAPSHOT, Java 25)
• observation: drop a hardcoded micrometer-tracing-bom import that was overriding the version managed by the parent BOM
• twitter-salesforce: repair a broken Contact DTO and remove the reflection that was standing in for it. The route used Class.forName to prefer a Contact DTO generated by camel-salesforce-maven-plugin (only present when built with -Dgenerate.dto against a live org) and otherwise fall back to a bundled DTO. But Class.forName(x) != null never returns false — a missing class throws ClassNotFoundException immediately, so the fallback branch was dead code, and the bundled fallback DTO was itself an abstract class that didn't extend AbstractSObjectBase, so it could neither be instantiated nor be recognized by the Salesforce component. Without running the generate.dto profile, every tweet mention failed.
  • Replaced the abstract draftdto.Contact with a concrete example.mention.dto.Contact extending AbstractSObjectBase, with @JsonProperty annotations preserving Salesforce's case-sensitive field API names (LastName, TwitterScreenName__c) — without them Jackson decapitalizes the leading letter of bean-derived property names and would silently send the wrong field names
  • Then removed the reflection entirely: the route only ever calls the same two setters regardless of which DTO class is used, and upsertSObject's create/update path only casts the body to AbstractSObjectBase — it never uses the generated DTO's extra fields or its SObjectDescription metadata. So preferring the generated class had no effect on behavior, only an extra failure mode. The route now references the bundled Contact DTO directly
  • Pinned build-helper-maven-plugin to 3.0.0, matching other examples in this repo
  • Kept the generate-salesforce-dto profile / camel-salesforce-maven-plugin wiring as documented, optional tooling for extending the route to more fields — just no longer glued to it via reflection
  • Clarified in the README that the bundled Twitter/X and Salesforce credentials are illustrative placeholders (the Twitter ones predate the 2023 API overhaul and are very likely dead) that must be replaced with self-provisioned ones

Test plan

• rest-openapi: built and ran the example; verified /actuator returns 200 and /actuator/ returns 404; verified /api/users (CRUD), /api/api-doc, and /actuator/prometheus all work as documented
• observation: confirmed the tracing bom version now comes cleanly from the parent BOM with no overrides
• twitter-salesforce: mvn compile succeeds offline with no Salesforce credentials; verified via a standalone harness that the Contact DTO instantiates, extends AbstractSObjectBase, and serializes with the correct Salesforce field casing (LastName, TwitterScreenName__c)