docs/backend-system: move naming pattern docs

Signed-off-by: Patrik Oldsberg <poldsberg@gmail.com>

docs/auth/identity-resolver.md

@@ -193,7 +193,7 @@ backend.add(import('@backstage/plugin-auth-backend-module-github-provider'));
 backend.add(customAuth);
 ```
 
-Check out [the naming patterns article](../backend-system/architecture/07-naming-patterns.md) for what rules
+Check out [the naming patterns article](../backend-system/architecture/08-naming-patterns.md) for what rules
 apply regarding how to form valid IDs. In this example we also put the module
 declaration directly in `packages/backend/src/index.ts` but that's just for
 simplicity. You can place it anywhere you like, including in other packages, and

docs/backend-system/architecture/03-services.md

@@ -38,7 +38,7 @@ export const fooServiceRef = createServiceRef<FooService>({
 
 The `fooServiceRef` that we create above should be exported, and can then be used to declare a dependency on the `FooService` interface and receive an implementation of it at runtime.
 
-When creating a service reference you need to give it an ID. This ID needs to be globally unique, and should generally be of the format `'<pluginId>.<serviceName>'`. For more naming patterns surrounding services, see the [naming patterns](./07-naming-patterns.md#services) page.
+When creating a service reference you need to give it an ID. This ID needs to be globally unique, and should generally be of the format `'<pluginId>.<serviceName>'`. For more naming patterns surrounding services, see the [naming patterns](./08-naming-patterns.md#services) page.
 
 A note on naming: the frontend and backend systems intentionally use the separate names "APIs" and "Services" for concepts that are quite similar. This is to avoid confusion between the two, both in documentation and discussion, but also in code. While the two systems are quite similar, they are not identical, and they can't be used interchangeably.
 

docs/backend-system/architecture/04-plugins.md

@@ -10,7 +10,7 @@ Plugins provide the actual base features of a Backstage backend. Each plugin ope
 
 ## Defining a Plugin
 
-Plugins are created using the `createBackendPlugin` function, and should typically be exported from a plugin package. All plugins must have an ID and a `register` method, where the ID matches the plugin ID in the package name, without the `-backend` suffix. See also the [dedicated section](./07-naming-patterns.md) about proper naming patterns.
+Plugins are created using the `createBackendPlugin` function, and should typically be exported from a plugin package. All plugins must have an ID and a `register` method, where the ID matches the plugin ID in the package name, without the `-backend` suffix. See also the [dedicated section](./08-naming-patterns.md) about proper naming patterns.
 
 ```ts
 // plugins/example-backend/src/plugin.ts

docs/backend-system/building-plugins-and-modules/01-index.md

@@ -68,7 +68,7 @@ that's specific to your plugin. In the example above, the logger might tag
 messages with your plugin ID, and the HTTP router might prefix API routes with
 your plugin ID, depending on the implementation used.
 
-See [the article on naming patterns](../architecture/07-naming-patterns.md) for
+See [the article on naming patterns](../architecture/08-naming-patterns.md) for
 details on how to best choose names/IDs for plugins and related backend system
 items.
 
@@ -124,7 +124,7 @@ export const catalogModuleExampleCustomProcessor = createBackendModule({
 export { catalogModuleExampleCustomProcessor as default } from './module';
 ```
 
-See [the article on naming patterns](../architecture/07-naming-patterns.md) for
+See [the article on naming patterns](../architecture/08-naming-patterns.md) for
 details on how to best choose names/IDs for modules and related backend system
 items.