room_server: add system post helper for local events

[Che177]

Draft PR for discussion, based on issue #2686.

I am opening this as a draft because this touches the room server structure/API shape. Happy to adjust the approach based on maintainer feedback!

Summary

This PR adds a small helper method that allows simple_room_server to create a room post as the room server itself.

The main change is:

MyMesh::addSystemPost(const char* postData)

This provides a clean code path for local/server-side events to create room posts without duplicating the existing post storage and push logic.

The helper is also exposed through a console command:

room.post <message>

This makes room-server-originated posts easy to test manually from the serial console.

A disabled-by-default GPIO contact example is included as a practical demo use case.

Motivation

The room server can be useful as a local message source.
I wanted to make that concept available as a small helper method so local room-server events can post into the room cleanly.

As a practical demo, I added a disabled-by-default GPIO contact example for the use case I was working on:

• equipment box opened
• dry contact closes
• room server posts a message into the chat

Example deployment-specific message:

Equipment box opened

Implementation

This PR:

• adds MyMesh::addSystemPost(const char* postData)
• uses the room server’s own identity for system posts
• reuses the existing storePost() path
• keeps post indexing, timestamping, push scheduling, and sync behavior consistent with normal room posts
• exposes the helper through the room.post <message> console command
• adds optional GPIO contact handling in examples/simple_room_server/main.cpp
• keeps GPIO contact input disabled by default
• includes commented PlatformIO flags as a development/testing example

The commented PlatformIO example is currently included in:

variants/lilygo_tlora_v2_1/platformio.ini

[env:LilyGo_TLora_V2_1_1_6_room_server]

Known limitation

This follows the current room server timestamp behavior.

The room server clock needs to be synchronized before local/system posts are created. Otherwise, the post may be timestamped in the past and may not appear as expected in the client room view.

This appears to be a limitation of the current room post timestamp design, not something specific to the GPIO contact example.

Scope

This PR does not add a general sensor framework.

It does not introduce protocol changes, app changes, or new dependencies.

The GPIO contact input is intended only as a small example of a local event source that can call the new system post helper.

Testing

Tested locally with simple_room_server.

Verified:

• console room.post <message> can create a room post through addSystemPost()
• a GPIO dry-contact change can create a room post through addSystemPost() when the optional contact input is enabled
• posts appear as expected after the room server clock is synchronized