Restore truncated mesh.proto content and keep intended lockdown schema changes

[Copilot]

What does this PR do?

Restores the accidentally truncated tail of meshtastic/mesh.proto that caused Buf type-resolution failures in PR #927, while preserving only the intended lockdown-related schema additions and valid comment edits.

Related context: pull-request workflow buf build failed on missing symbols (DeviceMetadata, NodeRemoteHardwarePin, MyNodeInfo, MeshPacket, StatusMessage).

• Root cause

  • mesh.proto was unintentionally cut after RouteDiscovery and replaced with a placeholder comment, removing a large set of message/enum definitions required by other proto files.

• Schema changes kept (intended PR behavior)

  • meshtastic/admin.proto
    • Added AdminMessage.LockdownAuth.disable as field 6 with the submitted documentation.
  • meshtastic/mesh.proto
    • Added FromRadio.LockdownStatus.State.DISABLED = 5.

• Content restoration

  • Reinstated the full post-RouteDiscovery section in mesh.proto, including definitions referenced by failing files (e.g. StatusMessage, MeshPacket, MyNodeInfo, DeviceMetadata, NodeRemoteHardwarePin).

• Non-functional edits preserved

  • Kept the small comment text/format updates in mesh.proto (MeshLink description and STATION_G3 comment alignment).

message LockdownAuth {
  // ...
  bool disable = 6;
}

message LockdownStatus {
  enum State {
    // ...
    DISABLED = 5;
  }
}

Checklist before merging

• All top level messages commented
• All enum members have unique descriptions

New Hardware Model Acceptance Policy

Due to limited availability and ongoing support, new Hardware Models will only be accepted from Meshtastic Backers and Partners. The Meshtastic team reserves the right to make exceptions to this policy.

Alternative for Community Contributors

You are welcome to use one of the existing DIY hardware models in your PlatformIO environment and create a pull request in the firmware project. Please note the following conditions:

• The device will not be officially supported by the core Meshtastic team.
• The device will not appear in the Web Flasher or Github release assets.
• You will be responsible for ongoing maintenance and support.
• Community-contributed / DIY hardware models are considered experimental and will likely have limited or no testing.

Getting Official Support

To have your hardware model officially supported and included in the Meshtastic ecosystem, consider becoming a Meshtastic Backer or Partner. Visit meshtastic.com for more information about partnership opportunities.

Original prompt

Fix pull request #927 in meshtastic/protobufs. The PR branch is feature/lockdown-disable and the failing CI job is job 78378405719 from the pull-request workflow.

Context:

• Repository: meshtastic/protobufs
• PR: Add lockdown disable + DISABLED status for runtime lockdown toggle #927
• Base branch: develop
• Head SHA: 5bb3a33abd96811a8aa4558437a3c7054c14c165
• Workflow file: .github/workflows/pull_request.yml
• The failing step is the Buf validation step (bufbuild/buf-action@v1.2.0) running buf build.

Observed failure from the job logs:

• cannot find DeviceMetadata in this scope
• cannot find NodeRemoteHardwarePin in this scope
• cannot find MyNodeInfo in this scope
• cannot find MeshPacket in this scope
• cannot find StatusMessage in this scope
• Failed build

Files changed in the PR:

• meshtastic/admin.proto
• meshtastic/mesh.proto

Important clue:
The PR appears to have unintentionally truncated or removed a very large portion of meshtastic/mesh.proto after the RouteDiscovery message, replacing the remainder with a placeholder comment:
/* remaining file unchanged for brevity in this commit payload */

The deleted section includes definitions for symbols that Buf can no longer resolve, including at least:

• StatusMessage
• MeshPacket
• MyNodeInfo
• DeviceMetadata
• NodeRemoteHardwarePin

Task:

1. Inspect the PR branch changes and confirm the root cause.
2. Restore the accidentally removed content from meshtastic/mesh.proto so that the file once again contains the missing message/enum definitions.
3. Preserve the intended PR changes only:
   • in meshtastic/admin.proto, add AdminMessage.LockdownAuth.disable as field 6 with the provided documentation
   • in meshtastic/mesh.proto, add FromRadio.LockdownStatus.State.DISABLED = 5
   • preserve the small comment-only formatting/text edits in mesh.proto if they are valid
4. Ensure buf build/PR checks pass.
5. Open a pull request with the fix against the appropriate branch/repository context for this task.

Please keep the fix minimal and do not introduce unrelated refactors.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for failing job 78378405719. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The failure is a Buf build/type-resolution error, not a workflow bug.

What’s failing

In the PR workflow, the only relevant step is the Buf validation step in .github/workflows/pull_request.yml:

• .github/workflows/pull_request.yml:16-23 runs Buf with format, lint, and breaking checks
• Source: https://github.com/meshtastic/protobufs/blob/5bb3a33abd96811a8aa4558437a3c7054c14c165/.github/workflows/pull_request.yml

The failing job log shows unresolved protobuf type references during buf build:

• cannot find DeviceMetadata in this scope
• cannot find NodeRemoteHardwarePin in this scope
• cannot find MyNodeInfo in this scope
• cannot find MeshPacket in this scope
• cannot find StatusMessage in this scope

Root cause

One or more .proto files in this PR are referring to message types that are no longer in scope from Buf’s point of view. That almost always means one of these happened:

1. An import was removed or is missing
2. A type name was changed but references were not updated
3. A package changed, so the type now needs its fully qualified name
4. A file was moved and Buf no longer sees the symbol through the previous import path

Because the missing symbols are all Meshtastic message types, the most likely issue is a missing import or wrong package qualification in the modified .proto file(s).

Fix

Update the changed .proto file(s) so every referenced message type is either:

• imported from the file where it is defined, and/or
• referenced with the correct package-qualified name

What to change

For any file that uses these symbols:

• DeviceMetadata
• NodeRemoteHardwarePin
• MyNodeInfo
• MeshPacket
• StatusMessage

make sure it imports the defining proto file, for example:

import "meshtastic/mesh.proto";

or whatever the current canonical path is in this repo for those message definitions.

If the file is in a different package, use fully qualified names instead of bare names, for example:

meshtastic.MeshPacket packet = 1;
meshtastic.MyNodeInfo node_info = 2;
meshtastic.DeviceMetadata metadata = 3;
meshtastic.StatusMessage status = 4;
meshtastic.NodeRemoteHardwarePin pin = 5;

Concrete code suggestion

If the PR introduced a new proto file or split an existing one, the fix will look like this pattern:

syntax = "proto3";

package meshtastic.somepackage;

import "meshtastic/mesh.proto"; // adjust to actual defining file

message Example {
  meshtastic.MeshPacket packet = 1;
  meshtastic.MyNodeInfo node_info = 2;
  meshtastic.DeviceMetadata metadata = 3;...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>