Repair the easy-to-fix Kramdown issues

These Kramdown issues are relatively easy to fix, and don't require
a long pipeline.

doc/development/cascading_settings.md

@@ -82,7 +82,7 @@ cascading_attr :delayed_project_removal
 - `delayed_project_removal_locked_by_ancestor?`
 - `delayed_project_removal_locked_by_application_setting?`
 - `delayed_project_removal?` (Boolean attributes only)
-- `delayed_project_removal_locked_ancestor` (Returns locked namespace settings object [namespace_id])
+- `delayed_project_removal_locked_ancestor` (Returns locked namespace settings object `[namespace_id]`)
 
 ### Attribute reader method (`delayed_project_removal`)
 

doc/development/sidekiq_style_guide.md

@@ -539,7 +539,7 @@ The `feature_flag` property does not allow the use of
 This means that the feature flag cannot be toggled only for particular
 projects, groups, or users, but instead, you can safely use [percentage of time rollout](../development/feature_flags/index.md).
 Note that since we check the feature flag on both Sidekiq client and server, rolling out a 10% of the time,
-will likely results in 1% (0.1 [from client]*0.1 [from server]) of effective jobs using replicas.
+will likely results in 1% (`0.1` `[from client]*0.1` `[from server]`) of effective jobs using replicas.
 
 Example: