Fix '--get security' (incorrect AdminMessage.ConfigType value).

[cpatulea]

requestConfig was assuming that the order of fields in meshtastic.LocalConfig matches the order of enum values in AdminMessage.ConfigType. This is true for 'device', 'position', etc. but is NOT true for 'security' due to the intervening 'version' field.

Look up config fields by name, not index, to prevent this error in the future.

LocalConfig.security was introduced in meshtastic/protobufs#553

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 59.81%. Comparing base (d0ccb1a) to head (918e30e).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
meshtastic/node.py	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #907      +/-   ##
==========================================
- Coverage   59.82%   59.81%   -0.01%     
==========================================
  Files          24       24              
  Lines        4329     4328       -1     
==========================================
- Hits         2590     2589       -1     
  Misses       1739     1739              

Flag	Coverage Δ
unittests	59.81% <50.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Fixes an incorrect --get security behavior in the Meshtastic Python CLI/library by ensuring Node.requestConfig() maps LocalConfig fields to AdminMessage.ConfigType by enum name rather than relying on protobuf field ordering.

Changes:

• Update Node.requestConfig() to derive AdminMessage.ConfigType from the LocalConfig field name (fixing security mapping).
• Keep module config requests using the prior index-based behavior.

[Copilot]

AdminMessage.ConfigType.Value(configType.name.upper() + "_CONFIG") will raise ValueError if a LocalConfig field doesn’t have a corresponding ConfigType enum (e.g. LocalConfig.version). Because requestConfig() is reachable from the CLI via --get <field>, this becomes an uncaught exception for a user typo/unsupported field. Consider catching the error (or checking membership in the enum) and exiting with a clear message (or explicitly rejecting version).

Suggested change

	p.get_config_request = admin_pb2.AdminMessage.ConfigType.Value(configType.name.upper() + "_CONFIG")
	enum_name = configType.name.upper() + "_CONFIG"
	# Validate that the constructed enum name exists to avoid ValueError from .Value()
	if enum_name not in admin_pb2.AdminMessage.ConfigType.keys():
	our_exit(
	f"Unsupported configuration field '{configType.name}' cannot be requested.",
	1,
	)
	p.get_config_request = admin_pb2.AdminMessage.ConfigType.Value(enum_name)

[cpatulea]

I think the current behavior is good. Any future changes should be made together on LocalConfig and ConfigType. If there's a mismatch, this should raise an exception, to alert the developers (or the users in the worst case) that there's a bug.