docs(sips/006-spin-plugins): Fix typo in package.os field definitio…

…n (`osx` -> `macos`)

At the time of writing (Spin v3.1.2), the `Os` enum is [defined][0] as follows:

```rs
enum Os {
    Linux,
    Macos,
    Windows,
}
```

This commit adjust the SIP to match the implementation by renaming `osx` to `macos`. Note that the SIP later on uses `macos` as part of the URL in one of the examples.

[0]: https://github.com/fermyon/spin/blob/v3.1.2/crates/plugins/src/manifest.rs#L113

Signed-off-by: Petar Kirov <[email protected]>

docs/content/sips/006-spin-plugins.md

@@ -159,7 +159,7 @@ A Spin plugin is defined by a Spin Plugin Manifest which is a JSON file that con
                         "type": "string",
                         "enum": [
                             "linux",
-                            "osx",
+                            "macos",
                             "windows"
                         ]
                     },
@@ -227,4 +227,4 @@ While for now plugins are assumed to be executables, in the future, support for
 
 The proposed method of using version strings to declare compatibility between a plugin and Spin has several drawbacks. Firstly, this requires plugin creators to stay involved with their contribution, regularly testing and updating the compatibility of their plugin with Spin. One way to make this more hands-off would be to encourage plugin creators to also contribute an integration test. For each new spin release, a workflow in the plugins repository can automatically run these integration tests and bump compatibility versioning on success. This is a strategy taken by [MicroK8s](https://microk8s.io/docs/addons) for its core and community add-ons.
 
-Another issue with using versioning to check for compatibility with Spin is that canary releases of Spin have the same version as the latest release. This means that if a user is using main or canary Spin, when Spin checks its version before installing a plugin, it may incorrectly assume compatibility even though its feature set is beyond that of the latest stable release. Spin templates currently have a workaround for detecting and handling this inconsistency. A more ideal way of assessing compatibility would be via capability checking wherein a plugin could declare what set of features it is compatible with and Spin would assert if those exist. For example, a plugin could be compatible with only a specific version of Spin manifests or only have support for WAGI. While a system like this would be full-proof, it would require deep design. As plugins are developed, a better understanding will come of what capabilities plugins need from Spin. From this, compatibility via compatibilities system could be designed.
+Another issue with using versioning to check for compatibility with Spin is that canary releases of Spin have the same version as the latest release. This means that if a user is using main or canary Spin, when Spin checks its version before installing a plugin, it may incorrectly assume compatibility even though its feature set is beyond that of the latest stable release. Spin templates currently have a workaround for detecting and handling this inconsistency. A more ideal way of assessing compatibility would be via capability checking wherein a plugin could declare what set of features it is compatible with and Spin would assert if those exist. For example, a plugin could be compatible with only a specific version of Spin manifests or only have support for WAGI. While a system like this would be full-proof, it would require deep design. As plugins are developed, a better understanding will come of what capabilities plugins need from Spin. From this, compatibility via compatibilities system could be designed.