chore: code fencing for gh actions defined at builds.yml (MetaMask#26159)

<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**

Wire Metro’s code-fence removal to **builds.yml** on GitHub Actions
while keeping Bitrise/local behavior unchanged.

**Why:** On GH Actions, build config (and thus which features are
enabled) comes from `builds.yml` via `apply-build-config.js`, which can
set `CODE_FENCING_FEATURES`. Metro previously only used
`METAMASK_BUILD_TYPE` and `METAMASK_ENVIRONMENT`, so code fencing did
not follow the same source of truth.

**What changed:**

- **GH Actions:** When `CODE_FENCING_FEATURES` is set, Metro uses that
JSON array for code-fence removal; `INCLUDE_SAMPLE_FEATURE` still adds
`sample-feature` when set.
- **Bitrise/local:** When `CODE_FENCING_FEATURES` is not set, behavior
is unchanged: features are derived from `METAMASK_BUILD_TYPE` +
`METAMASK_ENVIRONMENT` via `getBuildTypeFeaturesFromEnv()`.
- **Safety:** The env-based fallback returns new `Set` instances so
adding `sample-feature` (or other mutations) does not mutate shared
global sets.
- **Docs:** Comments and JSDoc clarify the “legacy” (Bitrise/local) vs
“GH Actions” paths.

**Scope:** Only `metro.transform.js` (no workflow or script changes in
this PR).

---

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry: Added code fencing for gh actions defined at builds.yml

## **Related issues**

Fixes: 

## **Manual testing steps**

```gherkin
Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**
checking code fencing in all builds ✅ 
main-rc
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/75d11555-3f76-4f80-bb48-c6a45cb99d64"
/>
main-exp
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/04487ad6-359c-448c-9660-f2e139f88dbf"
/>
main-test
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/319eb592-691f-4abe-93f3-f3a0467ac0bc"
/>
main-beta
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/c38416cb-706f-488f-a031-bcac2d811d8c"
/>
flask-test
<img width="280" height="675" alt="main-test"
src="https://github.com/user-attachments/assets/12224fd6-6ac2-4726-b7f4-43ca10ea2f59"
/>


## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **Pre-merge reviewer checklist**

- [x] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [x] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.



<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Changes the source of truth for code-fence feature gating in CI
builds, so misconfigured `CODE_FENCING_FEATURES` could include/exclude
fenced code unexpectedly across release flavors.
> 
> **Overview**
> Metro’s code-fence removal now **prefers `CODE_FENCING_FEATURES` (JSON
from `builds.yml` via CI)** as the active feature set, falling back to
the prior `METAMASK_BUILD_TYPE`/`METAMASK_ENVIRONMENT` logic when unset.
> 
> `builds.yml` expands code-fencing anchors to explicitly define `beta`
and `experimental` feature sets, and updates the `main-beta` and
`main-exp` build configs to use them; the Metro fallback path also now
returns fresh `Set` instances to avoid mutating shared feature sets when
optionally adding `sample-feature`.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
c474217. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Wei Sun <wei.sun@consensys.net>

Author: tommasini

builds.yml

@@ -120,6 +120,26 @@ _code_fencing_main: &code_fencing_main
   - bitcoin
   - tron
 
+# Beta code fencing features (main + beta feature)
+_code_fencing_beta: &code_fencing_beta
+  - beta
+  - preinstalled-snaps
+  - keyring-snaps
+  - multi-srp
+  - solana
+  - bitcoin
+  - tron
+
+# Experimental code fencing features (main + experimental)
+_code_fencing_experimental: &code_fencing_experimental
+  - preinstalled-snaps
+  - keyring-snaps
+  - multi-srp
+  - solana
+  - bitcoin
+  - tron
+  - experimental
+
 # Flask code fencing features (includes experimental)
 _code_fencing_flask: &code_fencing_flask
   - flask
@@ -186,7 +206,7 @@ builds:
       METAMASK_ENVIRONMENT: 'beta'
       METAMASK_BUILD_TYPE: 'main'
     secrets: *secrets
-    code_fencing: *code_fencing_main
+    code_fencing: *code_fencing_beta
     remote_feature_flags: *remote_feature_flags
 
   # Release candidate
@@ -260,7 +280,7 @@ builds:
       IS_TEST: 'false'
       MM_ENABLE_SETTINGS_PAGE_DEV_OPTIONS: 'true'
     secrets: *secrets
-    code_fencing: *code_fencing_main
+    code_fencing: *code_fencing_experimental
     remote_feature_flags:
       <<: *remote_feature_flags
       # Override for experimental testing

metro.transform.js

@@ -12,6 +12,8 @@ const svgTransformer = require('react-native-svg-transformer');
 
 // Code fence removal variables
 const fileExtsToScan = ['.js', '.jsx', '.cjs', '.mjs', '.ts', '.tsx'];
+
+// All available features that can be used in code fences
 const availableFeatures = new Set([
   'flask',
   'preinstalled-snaps',
@@ -26,6 +28,7 @@ const availableFeatures = new Set([
   'experimental',
 ]);
 
+// Legacy (main) hardcoded feature sets — used when CODE_FENCING_FEATURES is not set (e.g. Bitrise / local)
 const mainFeatureSet = new Set([
   'preinstalled-snaps',
   'keyring-snaps',
@@ -53,51 +56,71 @@ const flaskFeatureSet = new Set([
   'solana',
   'tron',
 ]);
-// Experimental feature set includes all main features plus experimental
 const experimentalFeatureSet = new Set([...mainFeatureSet, 'experimental']);
 
 /**
- * Gets the features for the current build type, used to determine which code
- * fences to remove.
+ * Gets features from METAMASK_BUILD_TYPE + METAMASK_ENVIRONMENT (main branch logic).
+ * Used when CODE_FENCING_FEATURES is not set (Bitrise or local).
  *
  * @returns {Set<string>} The set of features to be included in the build.
  */
-function getBuildTypeFeatures() {
+function getBuildTypeFeaturesFromEnv() {
   const buildType = process.env.METAMASK_BUILD_TYPE ?? 'main';
   const envType = process.env.METAMASK_ENVIRONMENT ?? 'production';
   let features;
 
   switch (buildType) {
-    // TODO: Remove uppercase QA once we've consolidated build types
     case 'qa':
     case 'QA':
     case 'main':
-      // TODO: Refactor this once we've abstracted environment away from build type
       if (envType === 'exp') {
-        // Only include experimental features in experimental environment
-        features = experimentalFeatureSet;
+        features = new Set(experimentalFeatureSet);
         break;
       }
-      features = envType === 'beta' ? betaFeatureSet : mainFeatureSet;
+      features =
+        envType === 'beta' ? new Set(betaFeatureSet) : new Set(mainFeatureSet);
       break;
     case 'beta':
-      features = betaFeatureSet;
+      features = new Set(betaFeatureSet);
       break;
     case 'flask':
-      features = flaskFeatureSet;
+      features = new Set(flaskFeatureSet);
       break;
     default:
       throw new Error(
         `Invalid METAMASK_BUILD_TYPE of ${buildType} was passed to metro transform`,
       );
   }
 
-  // Add sample-feature only if explicitly enabled via env var
+  return features;
+}
+
+/**
+ * Gets the features for the current build type, used to determine which code
+ * fences to remove.
+ *
+ * Default (GH Actions): use CODE_FENCING_FEATURES from env (set by apply-build-config.js from builds.yml).
+ * Fallback (Bitrise / local): use METAMASK_BUILD_TYPE + METAMASK_ENVIRONMENT with hardcoded sets.
+ *
+ * @returns {Set<string>} The set of features to be included in the build.
+ */
+function getBuildTypeFeatures() {
+  let featureSet;
+
+  // Prefer GH Actions path: single source of truth from builds.yml
+  if (process.env.CODE_FENCING_FEATURES) {
+    const features = JSON.parse(process.env.CODE_FENCING_FEATURES);
+    featureSet = new Set(features);
+  } else {
+    // Fallback for Bitrise / local dev builds
+    featureSet = getBuildTypeFeaturesFromEnv();
+  }
+
   if (process.env.INCLUDE_SAMPLE_FEATURE === 'true') {
-    features.add('sample-feature');
+    featureSet.add('sample-feature');
   }
 
-  return features;
+  return featureSet;
 }
 
 /**