docs: RLS and wrapper Key changes (#45166)

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
* Updated SDK initialization examples to reflect current authentication
patterns across multiple Supabase integration guides
* Enhanced security documentation with expanded guidance on protecting
sensitive credentials like secrets and service role keys in frontend and
Edge Function environments
* Clarified Row-Level Security access patterns and data availability
considerations when using publishable keys

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: fadymak <dev@fadymak.com>

apps/docs/content/guides/api/using-custom-schemas.mdx

@@ -63,7 +63,7 @@ const { data: todos, error } = await supabase.schema('myschema').from('todos').s
 // Initialize the Flutter client
 await Supabase.initialize(
   url: supabaseUrl,
-  anonKey: supabaseKey,
+  publishableKey: publishableKey,
   postgrestOptions: const PostgrestClientOptions(schema: 'myschema'),
 );
 final supabase = Supabase.instance.client;

apps/docs/content/guides/database/extensions/pg_net.mdx

@@ -352,7 +352,7 @@ Make a POST request to a Supabase Edge Function with auth header and JSON body p
 select
     net.http_post(
         url:='https://project-ref.supabase.co/functions/v1/function-name',
-        headers:='{"Content-Type": "application/json", "Authorization": "Bearer <YOUR_ANON_KEY>"}'::jsonb,
+        headers:='{"Content-Type": "application/json", "apikey": "<SUPABASE_PUBLISHABLE_KEY>"}'::jsonb,
         body:='{"name": "pg_net"}'::jsonb
     ) as request_id;
 ```
@@ -370,7 +370,7 @@ select cron.schedule(
 	    select "net"."http_post"(
             -- URL of Edge function
             url:='https://project-ref.supabase.co/functions/v1/function-name',
-            headers:='{"Authorization": "Bearer <YOUR_ANON_KEY>"}'::jsonb,
+            headers:='{"apikey": "<SUPABASE_PUBLISHABLE_KEY>"}'::jsonb,
             body:='{"name": "pg_net"}'::jsonb
 	    ) as "request_id";
 	$$

apps/docs/content/guides/database/postgres/row-level-security.mdx

@@ -57,7 +57,7 @@ You can enable RLS for any table using the `enable row level security` clause:
 alter table "table_name" enable row level security;
 ```
 
-Once you have enabled RLS, no data will be accessible via the [API](/docs/guides/api) when using the public `anon` key, until you create policies.
+Once you have enabled RLS, no data will be accessible via the [API](/docs/guides/api) when using a publishable key, until you create policies.
 
 ## Auto-enable RLS for new tables
 

apps/docs/content/guides/database/secure-data.mdx

@@ -15,7 +15,7 @@ Use Supabase client libraries, REST, or GraphQL with a publishable key. Protect
 
 ### Edge Functions
 
-Put custom server-side logic between your client and database with [Edge Functions](/docs/guides/functions). You can use secrets, service role keys, or database connection strings inside the function, and you can [disable the Data API](/docs/guides/database/data-api#disable-the-data-api-completely) if your app only accesses data this way.
+Put custom server-side logic between your client and database with [Edge Functions](/docs/guides/functions). You can use secrets, API keys, or database connection strings inside the function, and you can [disable the Data API](/docs/guides/database/data-api#disable-the-data-api-completely) if your app only accesses data this way.
 
 ### Direct database connections
 
@@ -32,9 +32,9 @@ Your publishable key is safe to expose with RLS enabled, because row access perm
 
 Older projects may also show an `anon` key. Treat it like a publishable key: it can identify your project, but it is not a secret and must be paired with RLS and least-privilege grants.
 
-<Admonition type="danger" label="Never expose your service role key on the frontend">
+<Admonition type="danger" label="Never expose your service role or secret keys on the frontend">
 
-Unlike your publishable key, your **service role key** is **never** safe to expose because it bypasses RLS. Only use your service role key on the backend. Treat it as a secret (for example, import it as a sensitive environment variable instead of hardcoding it).
+Unlike your publishable key, your secret and service role keys are **never** safe to expose because they bypass RLS. Only use your secret and service role keys on the backend. Treat them as secrets (for example, import them as sensitive environment variables instead of hardcoding them).
 
 </Admonition>