feat(bridge): add core.list_methods RPC for method discovery

[Sanjays2402]

What

Adds a discoverable bridge endpoint — core.list_methods — that returns the canonical list of every RPC method the current build understands. Lets external clients (iOS app, future Android port, debug tooling, anyone wiring a new front end) enumerate the bridge surface at runtime instead of grepping bridge.rs.

Why

The bridge currently exposes 119 RPC methods with no programmatic way to discover them. New clients have to read source. Worse, there's no compile-time guarantee that a manually maintained method list would stay in sync.

How

1. New public constant BRIDGE_METHODS: &[&str] — sorted, 119 entries, one per dispatcher arm.

2. New RPC core.list_methods — returns

{
  "schema": "goose.bridge.methods-list.v1",
  "count": 119,
  "methods": ["activity.apply_correction", "activity.attach_interval", ...]
}

3. Drift-proof self-check tests:

• bridge_methods_constant_matches_dispatcher — scans the live dispatcher source via include_str! and asserts the extracted method set equals BRIDGE_METHODS. If anyone adds a new method without registering it in the constant, CI fails with a pointed message.
• bridge_methods_constant_is_sorted_and_unique — enforces the documented ordering / uniqueness invariant.
• core_list_methods_rpc_returns_full_method_set — round-trips the RPC through handle_bridge_request and verifies envelope + payload, including that core.list_methods is itself present in the list it advertises.

Compatibility

Non-breaking, purely additive — no existing method is touched. The new schema goose.bridge.methods-list.v1 is independent of goose.bridge.response.v1.

Tests

$ cargo test --lib bridge::tests::
running 12 tests
test bridge::tests::bridge_methods_constant_matches_dispatcher ... ok
test bridge::tests::bridge_methods_constant_is_sorted_and_unique ... ok
test bridge::tests::core_list_methods_rpc_returns_full_method_set ... ok
... (9 pre-existing tests)
test result: ok. 12 passed; 0 failed

Full cargo test --lib: 16 passed, 0 failed. cargo fmt --all applied. cargo build --lib clean.

Files

• Rust/core/src/bridge.rs — +251 / -0

[tigercraft4]

Manual constant requires two-site updates on every new method.

Whenever a bridge method is added, the developer must update both the dispatcher match arms and this constant. The drift test catches the omission at CI time, but only after a commit — there is no guard at editing time.

A cleaner approach: generate BRIDGE_METHODS at build time from a build script that parses the dispatcher, eliminating the manual step entirely. The drift test would then verify the build artifact rather than a hand-maintained list.

Note: the constant must be curated, not assumed-complete — not every match arm is a top-level RPC. The drift test only protects methods that are registered; it cannot detect a method added to the constant that was never wired into the dispatcher.

[tigercraft4]

Drift-test regex must exactly match the dispatch syntax or becomes a silent no-op.

The test scans bridge.rs source via include_str! and extracts method strings using string matching. If the formatting of match arms changes (multiline arms, macros, comments inside the block), the extraction may silently miss methods — the test passes while BRIDGE_METHODS is actually out of sync.

Suggest adding an assertion on the count of extracted methods as a sanity check:

assert!(
    extracted.len() >= BRIDGE_METHODS.len(),
    "Fewer methods extracted ({}) than registered ({}). \
     The extraction regex may not match all dispatch arms.",
    extracted.len(), BRIDGE_METHODS.len()
);

This catches the regex silently going blind without requiring it to be perfectly accurate.

Also worth considering: whether some entries in BRIDGE_METHODS are internal-only debug RPCs that should not be advertised to all callers via core.list_methods. Authorization at a higher layer may be needed before this endpoint is surfaced externally.