Change hints in tutorials (#717)

Hints were being used with syntax {{< hint info >}} rather than {{% hint info %}} which prevents markdown from being rendered within the block. Changing so that markdown renders correctly

Author: pbeckham

docs.kosli.com/content/tutorials/attest_snyk.md

@@ -13,10 +13,10 @@ Snyk scans analyze your source code, docker images and IaC source for security i
 
 In this tutorial, we will see how you can run and attest different types of Snyk scans to Kosli. We will run the scans on the [Kosli CLI git repo](https://github.com/kosli-dev/cli).
 
-{{<hint info>}}
+{{% hint info %}}
 While snyk attestations can be bound to a trail or an artifact in a trail, this tutorial
 demonstrates it only on trails for simplicity.
-{{</hint>}}
+{{% /hint %}}
 
 ## Getting ready
 
@@ -46,9 +46,9 @@ We will start by creating a flow in Kosli to contain Trails and Artifacts for th
 kosli create flow snyk-demo --use-empty-template
 ```
 
-{{<hint info>}}
+{{% hint info %}}
 `--use-empty-template` indicates that this flow does not have a predefined set of required attestations.
-{{</hint>}}
+{{% /hint %}}
 
 Then, we can start a trail to bind our snyk attestations to.
 
@@ -58,10 +58,10 @@ kosli begin trail test-1 --flow snyk-demo
 
 Now we can start running Snyk scans and attest them to this trail.
 
-{{<hint info>}}
+{{% hint info %}}
 After each attestation in the sections below, you can navigate to:
 **https://app.kosli.com/\<your-personal-org-name\>/flows/snyk-demo/trails/test-1** to view the status of the trail in Kosli.
-{{</hint>}}
+{{% /hint %}}
 
 ## Snyk Open source scan
 
@@ -74,9 +74,9 @@ snyk test --sarif-file-output=os.json
 kosli attest snyk --flow snyk-demo --trail test-1 --name open-source-scan --scan-results os.json --commit HEAD
 ```
 
-{{<hint info>}}
+{{% hint info %}}
 `--commit` allows you to relate the attestation to a specific git commit.
-{{</hint>}}
+{{% /hint %}}
 
 
 ## Snyk Code scan

docs.kosli.com/content/tutorials/cli_and_http_proxy.md

@@ -16,10 +16,10 @@ This tutorial shows how you can setup an HTTP proxy and use it when communicatin
 If you already have an HTTP proxy, [start using it with Kosli CLI](#use-the-http-proxy-with-kosli-cli)
 
 
-{{<hint info>}}
+{{% hint info %}}
 In this tutorial, we will setup Tinyproxy (in docker) as an HTTP proxy on a Mac machine.
 The same steps apply for different HTTP proxies and machines, but commands will differ.
-{{</hint>}}
+{{% /hint %}}
 
 
 ## Start the HTTP proxy

docs.kosli.com/content/tutorials/evaluate_trails_with_opa.md

@@ -23,9 +23,9 @@ To follow this tutorial, you need to:
   export KOSLI_API_TOKEN=<your-api-token>
   ```
 
-{{<hint info>}}
+{{% hint info %}}
 You don't need OPA installed — the Kosli CLI has a built-in Rego evaluator. You just need to write a `.rego` policy file.
-{{</hint>}}
+{{% /hint %}}
 
 ## Step 2: Write a policy
 
@@ -58,13 +58,13 @@ Let's break down what this policy does:
 * **`violations`** — a set of messages describing why the policy failed. The rule iterates over trails, then over pull requests within the `pull-request` attestation, looking for PRs where `approvers` is empty.
 * **`allow`** — trails are allowed only when there are no violations.
 
-{{<hint info>}}
+{{% hint info %}}
 **Policy contract** — these are Kosli-specific conventions, not OPA built-ins:
 
 * **`package policy`** — required. Kosli queries `data.policy.*` to find your rules.
 * **`allow`** — required. Must evaluate to a **boolean**. Kosli exits with code 0 when `true`, code 1 when `false`.
 * **`violations`** — optional but recommended. Must be a **set of strings**, where each string is a human-readable reason the policy failed. Kosli displays these when `allow` is `false`.
-{{</hint>}}
+{{% /hint %}}
 
 ## Step 3: Evaluate multiple trails
 
@@ -153,9 +153,9 @@ RESULT:  ALLOWED
 
 The trail has zero high-severity vulnerabilities, so the policy allows it.
 
-{{<hint info>}}
+{{% hint info %}}
 When writing a policy for `kosli evaluate trail`, reference `input.trail` (a single object). For `kosli evaluate trails`, reference `input.trails` (an array). The data shapes differ, so use separate policies for each command.
-{{</hint>}}
+{{% /hint %}}
 
 ## Step 5: Explore the policy input with --show-input
 
@@ -196,9 +196,9 @@ kosli evaluate trail \
 ]
 ```
 
-{{<hint info>}}
+{{% hint info %}}
 Use the `--attestations` flag to limit which attestations are enriched with full detail. The flag filters by **attestation name** (not type). For example, `--attestations pull-request` fetches only details for attestations named `pull-request`, which speeds up evaluation and reduces noise when exploring the input.
-{{</hint>}}
+{{% /hint %}}
 
 ## Step 6: Use in CI/CD
 
@@ -268,9 +268,9 @@ This creates a generic attestation on the trail with:
 * **`--user-data`** containing the violations, which appear in the Kosli UI as
   structured metadata on the attestation
 
-{{<hint warning>}}
+{{% hint warning %}}
 Use `--compliant=value` (with `=`) not `--compliant value` (with a space). Boolean
 flags in Kosli CLI require the `=` syntax when passing `false` — otherwise `false`
 is interpreted as a positional argument. See the
 [boolean flags FAQ](/faq/#boolean-flags).
-{{</hint>}}
+{{% /hint %}}

docs.kosli.com/content/tutorials/unauthorized_iac_changes.md

@@ -45,10 +45,10 @@ kosli create flow tf-tutorial --use-empty-template
 
 ## Making and tracking an authorized change
 
-{{<hint info>}}
+{{% hint info %}}
 In production, an authorized change will normally go though CI.
 In this tutorial, however, we run the commands that you would otherwise do in CI locally for simplicity.
-{{</hint>}}
+{{% /hint %}}
 
 Let's create a trail to represent a single instance of making an authorized change. We will call it `authorized-1`.
 
@@ -74,13 +74,13 @@ Finally, we apply the terraform plan, and attest the produced terraform state fi
 This will calculate a SHA256 fingerprint for the state file based on its contents. The fingerprint will later be used to determine if a change is 
 authorized or not.
 
-{{<hint info>}}
+{{% hint info %}}
 In this tutorial, we use a simple setup where the terraform state file is stored locally.
 In production cases, however, the state file would be stored in some cloud storage (e.g. AWS S3). 
 In such cases, you would need to download the state file from the remote backend after it was updated by the authorized change.
 
 Note that we set both `--build-url` and `--commit-url` to fake URLs. These are normally defaulted in CI.
-{{</hint>}}
+{{% /hint %}}
 
 ```shell {.command}
 terraform apply -auto-approve tf.plan
@@ -102,11 +102,11 @@ kosli create env terraform-state --type=server
 
 We can report the state file to the environment we created:
 
-{{<hint info>}}
+{{% hint info %}}
 In this tutorial, we run the environment reporting manually. 
 In production, you would configure the environment reporting to run periodically or on changes. 
 See [reporting AWS environments](../report_aws_envs) if you are using S3 as a backend for your state files.
-{{</hint>}}
+{{% /hint %}}
 
 ```shell {.command}
 kosli snapshot path terraform-state --name=tf-state --path=terraform.tfstate
@@ -140,10 +140,10 @@ terraform apply --auto-approve
 
 This updates the state file. Let's report the updated state file to the Kosli environment.
 
-{{<hint info>}}
+{{% hint info %}}
 In production, this step won't be necessary because you would have configured environment reporting to happen
 automatically (either on state file change or periodically).
-{{</hint>}}
+{{% /hint %}}
 
 ```shell {.command}
 kosli snapshot path terraform-state --name=tf-state --path=terraform.tfstate