Add missing getCurrentControlProfile implementation

[y-decimal]

control_profile.h defines a getCurrentControlProfile, but it was never implemented in control_profile.c, leading to issues for anyone wanting to use this function. This PR adds a simple implementation of said function.

The function iterares over index = 0, index < MAX_CONTROL_PROFILE_COUNT and checks if currentControlProfile == controlProfiles(index) for each index, until it finds a match.
If not match is found, it returns 0 instead.

I'm not sure if returning 0 is the best choice here, since it makes it impossible to tell if the index is genuinely just 0 or if something went wrong. I didn't want to return an arbitrary sentinel value like -1 without first checking in with you though since I'm not sure if there's an established convention or anything like that.

[qodo-code-review]

Review Summary by Qodo

Implement missing getCurrentControlProfile function

🐞 Bug fix

Walkthroughs

Description

• Implements missing getCurrentControlProfile function
• Iterates through control profiles to find current match
• Returns profile index or 0 if not found

Diagram

flowchart LR
  A["getCurrentControlProfile called"] --> B["Loop through profiles"]
  B --> C["Match found?"]
  C -->|Yes| D["Return profile index"]
  C -->|No| E["Return 0"]

Loading

File Changes

1. src/main/fc/control_profile.c 🐞 Bug fix +10/-0

Add getCurrentControlProfile function implementation

• Adds implementation of getCurrentControlProfile function
• Iterates through MAX_CONTROL_PROFILE_COUNT profiles
• Compares currentControlProfile with each profile entry
• Returns matching index or 0 if no match found

src/main/fc/control_profile.c

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1)

1. Ambiguous 0 profile index 📘 Rule violation ≡ Correctness

Description

getCurrentControlProfile() returns 0 when no matching profile is found, which is
indistinguishable from a valid profile index 0. This can cause callers to silently act on the
wrong control profile instead of detecting an invalid/no-match state.

Code

src/main/fc/control_profile.c[R105-113]

+uint8_t getCurrentControlProfile(void) {
+  for (uint8_t index = 0; index < MAX_CONTROL_PROFILE_COUNT; index++) {
+    if (currentControlProfile == controlProfiles(index)) {
+      return index;
+    }
+  }
+
+  return 0;
+}

Evidence

The compliance checklist requires explicit invalid/no-data sentinels instead of ambiguous defaults
like 0 when 0 can be a valid value. The new implementation returns 0 on the no-match path,
creating ambiguity between a valid index and an error/no-match condition.

src/main/fc/control_profile.c[105-113]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`getCurrentControlProfile()` returns `0` when no profile matches `currentControlProfile`, which is ambiguous because `0` is also a valid profile index.

## Issue Context
This code runs in embedded/task paths where ambiguous defaults can lead to silent misbehavior.

## Fix Focus Areas
- src/main/fc/control_profile.c[105-113]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Formatting inconsistent 🐞 Bug ⚙ Maintainability

Description

getCurrentControlProfile() uses different brace placement and indentation than the rest of
control_profile.c, increasing diff churn and risking formatter/style-check failures. This is
confined to the newly added function.

Code

src/main/fc/control_profile.c[R105-113]

+uint8_t getCurrentControlProfile(void) {
+  for (uint8_t index = 0; index < MAX_CONTROL_PROFILE_COUNT; index++) {
+    if (currentControlProfile == controlProfiles(index)) {
+      return index;
+    }
+  }
+
+  return 0;
+}

Evidence

The new function is written in a different style (brace on same line, 2-space indentation) while
surrounding functions in the same file use braces on the next line and 4-space indentation.

src/main/fc/control_profile.c[105-113]
src/main/fc/control_profile.c[86-103]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`getCurrentControlProfile()` formatting (brace placement and indentation) is inconsistent with the surrounding functions in `control_profile.c`.

### Issue Context
The rest of the file uses braces on the next line and 4-space indentation; aligning the new function reduces churn and avoids potential style-check/auto-format conflicts.

### Fix Focus Areas
- src/main/fc/control_profile.c[105-113]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Ambiguous 0 profile index 📘 Rule violation ≡ Correctness

getCurrentControlProfile() returns 0 when no matching profile is found, which is
indistinguishable from a valid profile index 0. This can cause callers to silently act on the
wrong control profile instead of detecting an invalid/no-match state.

Agent Prompt

## Issue description
`getCurrentControlProfile()` returns `0` when no profile matches `currentControlProfile`, which is ambiguous because `0` is also a valid profile index.

## Issue Context
This code runs in embedded/task paths where ambiguous defaults can lead to silent misbehavior.

## Fix Focus Areas
- src/main/fc/control_profile.c[105-113]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[MrD-RC]

Shouldn't it return the control profile, rather than the index? Surely if the index is returned the function should be named getCurrentControlProfileID()?

[y-decimal]

I didn't add the declaration in the header so I can only guess at the original author's intent. But the header file declares a uint8 as the return type, so I assume it was meant to return the index.
The alternative I think would be to remove the header declaration, considering how it had never been implemented and clearly wasn't needed until now.
I noticed it missing because I briefly considered using it in another feature I am working on currently, but that branch is very early in development and I might very well end up not needing it after all.

I suppose I maybe should've raised this as an issue first instead of jumping straight to a PR so it could be discussed in advance how to deal with it. I'll definitely keep that in mind for the future.

Let me know how you want to deal with this o7